Debian Squeeze est gelée

Posté par (page perso) . Modéré par baud123.
53
8
août
2010
Debian
Ça y est la future version stable de Debian est entrée en phase de gel. Les paquets de logiciels ne migrent plus automatiquement de "unstable" à "testing", seules les mises à jours correctives sont acceptées. À l'heure où cette dépêche est écrite, il reste 552 bogues critiques à corriger avant de publier la prochaine version stable, donc à tous les grincheux qui trouvent les sorties de Debian stable trop espacées dans le temps, à vos bugtrackers !

L'annonce a été faite en même temps par Neil McGovern sur la liste debian-devel-announce et par Adam D. Barratt lors du cycle de conférences DebConf (à New-York cette année). La sortie de Squeeze en version stable marquera un virage majeur dans l'histoire du projet GNU, puisque cette version sera la première vraie distribution à proposer l'ensemble des utilitaires GNU portés sur le noyau FreeBSD. Eh oui, parmi la dizaine d'architectures supportées s'est ajouté ce nouveau noyau ! Le projet Debian GNU/Hurd lui n'est toujours pas mort, mais n'est pas prévu pour cette version stable… ni pour une ultérieure semble-t-il. Cependant Debian est désormais la première distribution utilisable en production à gérer plusieurs architectures matérielles et plusieurs noyaux. (NdM : Il faut quand même noter que le port FreeBSD est présent en tant que « technology preview »)

D'autres évolutions majeures déjà présentes dans les versions stables d'autres distributions seront ajoutées comme un démarrage en parallèle qui repose sur le jeu des dépendances des services les uns aux autres et non sur un ordre d'exécution établi, des versions des logiciels plus récentes, un noyau Linux 2.6.32.

Le temps des grandes migration étant fini, seront donc présents dans Debian Squeeze :
  • GNOME 2.30
  • KDE 4.4.5
  • XFCE 4.6.2
  • LXDE 0.5.0
  • Python 2.6
  • et d'autres…
  • # Venez aider à la sortie de Squeeze !

    Posté par . Évalué à 9.

    Comme indiqué dans la traduction officielle (à l'instant finie) de l'annonce : http://www.debian.org/News/2010/20100806 , tout le monde est le bienvenue pour aider à la sortie de squeeze : correction des derniers problèmes critiques, tests de mises à niveau Lenny->Squeeze, mise à jour des notes de publication, traduction de toutes les documentations et communication autour de la nouvelle version.

    Donc n'hésitez pas à franchir le pas !
    • [^] # Re: Venez aider à la sortie de Squeeze !

      Posté par (page perso) . Évalué à 10.

      Moi je m'inquiète de voir que Squeeze est gelée avec Firefox (aka Iceweasel) en version 3.5.10.
      Il n'y aura pas de 3.6.x dans Squeeze ? Cette branche 3.6 est sortie en janvier dernier nom d'un chien ! Et en plus si on utilise une archi x86-64 je ne crois pas qu'on puisse télécharger un binaire sur le site de Mozilla donc on est coincé.
      • [^] # Re: Venez aider à la sortie de Squeeze !

        Posté par . Évalué à 7.

        Elle n'est déjà pas dans unstable (en tout cas chez moi c'est la 3.5.11), alors de là à se retrouver dans la stable... Enfin on est habitués je pense!
      • [^] # Re: Venez aider à la sortie de Squeeze !

        Posté par . Évalué à 5.

        Sur amd64 :
        $ apt-cache policy iceweasel
        iceweasel:
        Installé : 3.5.10-1
        Candidat : 3.5.10-1
        Table de version :
        3.6.7-1 0
        1 http://ftp.fr.debian.org experimental/main Packages
        3.5.11-1 0
        500 http://ftp.fr.debian.org sid/main Packages
        *** 3.5.10-1 0
        990 http://ftp.fr.debian.org squeeze/main Packages
        100 /var/lib/dpkg/status
        3.0.6-3 0
        500 http://ftp.fr.debian.org lenny/main Packages


        Y'a au moins experimental (qui n'a d'expérimental que le nom, j'en utilise quelques paquets)

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Venez aider à la sortie de Squeeze !

        Posté par (page perso) . Évalué à 3.

        Dans le même genre, Wormux est en 0.8.5 ce qui risque d'être gênant pour jouer en réseaux vu la durée de vie des versions. Espérons que des version plus à jour se retrouve dans les backports.

        « 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: Venez aider à la sortie de Squeeze !

        Posté par . Évalué à 10.

        • [^] # Re: Venez aider à la sortie de Squeeze !

          Posté par . Évalué à -7.

          Toujours aussi contre productif en ce qui concerne d'adoption de linux par le grand public...
          • [^] # Re: Venez aider à la sortie de Squeeze !

            Posté par . Évalué à 7.

            Pour les afficionados du web 2.0 et des fonds marrons, la même chose en forme de blog : http://glandium.org/blog/?p=891
            • [^] # Re: Venez aider à la sortie de Squeeze !

              Posté par (page perso) . Évalué à 6.

              Si l'on en croit la page officielle de FF 3.5 sur le site Mozilla, cette version ne sera plus maintenue à partir d'août 2010:

              "Firefox 3.5.x will be maintained with security and stability updates until August 2010"

              Source : http://www.mozilla.com/en-US/firefox/all-older.html

              Donc Debian va réussir l'exploit assez remarquable de sortir sa toute nouvelle Squeeze avec une version Firefox qui sera déjà abandonnée par l'upstream depuis plusieurs mois car complètement obsolète.
              Bon ça ne changera pas ma décision de basculer vers Debian car j'en ai soupé d'Ubuntu...mais en revanche je ne suis plus trop sûr d'opter pour l'archi x86-64. Si je reste en x86 classique je pourrais utiliser les binaires de Mozilla.
              • [^] # Re: Venez aider à la sortie de Squeeze !

                Posté par . Évalué à 8.

                Si tu prends 5 minutes le temps de lire les liens, tu verras que l'argument des mises à jour de sécurité de Firefox 3.5.x côté Mozilla n'est pas valable.
                En effet, les mises à jour de sécurité pour Firefox 3.6.x ne seront pas plus assurées par Mozilla sur la durée de vie d'une stable.
                Enfin je vais pas faire une redite des liens, le responsable des paquets Mozilla chez Debian fournit des explications claires à ce sujet.
                (Et n'oubliez pas que le projet est : 1/ bénévole 2/ ouvert aux bonnes volontés)
                • [^] # Re: Venez aider à la sortie de Squeeze !

                  Posté par (page perso) . Évalué à 4.

                  Oui j'ai vu ça dans les autres mails échangés...Mais c'est quand même gênant amha de sortir Squeeze avec un FF abandonné upstream.
                  Mais bon...je peux vivre avec et puis ce sera l'occasion d'essayer Epiphany et Chromium-browser ;-)
                  • [^] # Re: Venez aider à la sortie de Squeeze !

                    Posté par (page perso) . Évalué à 5.

                    Tu peux aussi ajouter les dépôts experimental et utiliser la dernière version de iceweasel (c'est ce que je fais).

                    « 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: Venez aider à la sortie de Squeeze !

                      Posté par . Évalué à 10.

                      On peut aussi ne pas utiliser Firefox du tout :-)

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Venez aider à la sortie de Squeeze !

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

                    Mais c'est quand même gênant amha de sortir Squeeze avec un FF abandonné upstream.

                    [Troll] A force tu vas finir à compatir à mes problèmes avec les repos ;-), perso je trouve que c'est même plus grave que gênant d'avoir une version aussi en retard à l'heure où FF4 est en route, est-ce que le système Debian est adapté au desktop et le web lorsque le web change aussi vite? Pour la partie "sécurité" je ne pense pas que ce soit trop gênant car Debian peut patcher sans trop de soucis à coup de backport des failles de sécu, mais c'est au niveau technologique que c'est plus inquiétant : comment montrer un Linux au top de la compatibilité avec les standards avec 2 versions de retard (3.6/4.0)? Je passerait sur le fait que tu ne peux pas exécuter leur binaire 32 bits si ton OS est 64 bits[/troll]

                    Plus sérieusement, un truc m'étonne : si j'ai bien compris, le problème est de passer de XUL Runner 1.9.1 à 1.9.2, il y a que moi que ça choque qu'une version mineure casse tout? La pierre ne serait-elle pas aussi à jeter à Mozilla pour ne pas stabiliser leurs sorties ou numéroter "bizarrement"? Au pire, pourquoi n'est-il pas possible facilement de faire tourner 2 versions de XUL Runner sur la même machine pour moins casser? Ca ne rentre pas dans la façon de faire de Debian? Est-ce une solution optimale?
                    • [^] # Re: Venez aider à la sortie de Squeeze !

                      Posté par . Évalué à 8.

                      est-ce que le système Debian est adapté au desktop

                      Est-ce que le système Debian stable est adapté au grand public?
                      Non, absolument pas. Du moins pas dès qu'il est confronté un peu trop au monde extérieur: protocoles d'IM proprios qui changent souvent, formats de bureautiques (propriétaires, mais aussi libres) qui évoluent, le Web que tu as cité.

                      Dommage, parce que Debian stable.. c'est Stable :)

                      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

                    • [^] # Re: Venez aider à la sortie de Squeeze !

                      Posté par (page perso) . Évalué à 5.

                      >>> perso je trouve que c'est même plus grave que gênant d'avoir une version aussi en retard à l'heure où FF4 est en route

                      D'après ce que j'ai cru comprendre la MoFo va proposer des binaires x86-64 pour Linux à partir de la version 4 de Firefox. Donc il n'y a plus que quelques mois à attendre (release en novembre 2010 normalement) et on pourra pallier à l'obsolescence du FF de Squeeze.
                      Aussi bien Squeeze ne sera pas encore sortie en novembre ;-)
                    • [^] # Re: Venez aider à la sortie de Squeeze !

                      Posté par . Évalué à 10.

                      perso je trouve que c'est même plus grave que gênant d'avoir une version aussi en retard à l'heure où FF4 est en route, est-ce que le système Debian est adapté au desktop et le web lorsque le web change aussi vite?

                      Nan mais sérieusement, vous pensez ce que vous dites ?

                      Je vois des commentaires qui se plaignent de ne pas avoir une version récente de wormux. Je vois des commentaires qui se plaignent de ne pas avoir une version récente de Firefox/iceweasel. Et maintenant un commentaire qui feint de s'interroger sur la pertinence de "Debian sur le desktop" (avec une pointe de mauvaise foi).

                      Hé ho, on se réveille. Debian stable, ce n'est pas fait pour faire de bleeding edge.

                      Ce n'est pas fait pour utiliser wormux ou iceweasel. Debian stable, c'est fait pour être installé avec un serveur DNS, un apache, un ldap, un smtp, un repo git, etc.

                      C'est pas fait pour aller sur youporn.

                      Même sur mes serveurs web j'ai du backport (pour drupal ou redmine par exemple).

                      Si c'est pour surfer, et encore plus pour un jeu (wormux, ce n'est pas tellement adapté au monde de l'entreprise), vous pouvez très bien prendre du testing/unstable voire même du experimental.

                      Et si ça ne vous va pas, utilisez Ubuntu ou autre chose. C'est juste que Debian n'est pas fait pour vous. Ce n'est pas grave, ça arrive aussi à des gens bien.


                      Debian peut patcher sans trop de soucis à coup de backport des failles de sécu Backport des patchs upstream plutôt.

                      comment montrer un Linux au top de la compatibilité avec les standards avec 2 versions de retard (3.6/4.0)? Bah tu ne montre pas. Si tu veux montrer une distrib GNU/Linux à un noob, tu montre compiz sur une testing ou une Ubuntu. Déjà, selon moi, ne serait-ce que pour avoir X sur une stable, il faut déjà être dans une niche. Alors Iceweasel, je n'en parle même pas (prétérition).
                      • [^] # Re: Venez aider à la sortie de Squeeze !

                        Posté par (page perso) . Évalué à 7.

                        Ce n'est pas fait pour utiliser wormux ou iceweasel.

                        Quel est l'imbécile qui les a mis dans les dépôts de stable alors?

                        Si c'est pour surfer, et encore plus pour un jeu (wormux, ce n'est pas tellement adapté au monde de l'entreprise), vous pouvez très bien prendre du testing/unstable voire même du experimental.

                        Wormux n'est pas à jour dans testing ni dans sid ni dans experimental.

                        Déjà, selon moi, ne serait-ce que pour avoir X sur une stable, il faut déjà être dans une niche.

                        Moi, j'installe du Debian stable chez des gens (avec les backports), je ne vois pas le problème (je chipote juste un peu pour avoir iceweasel à jour mais c'est tout et les gens sont content. C'est la même chose avec Ubuntu en LTS (sauf que les backports de Debian sont plus à jour).

                        « 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: Venez aider à la sortie de Squeeze !

                Posté par . Évalué à 6.

                De plus, pour une machine personnelle, on peut très bien vivre au jour le jour avec une testing, pas la peine de se restreindre à une stable.
                • [^] # Re: Venez aider à la sortie de Squeeze !

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

                  C'est clair :-)
                  Il y a même des distributions spécifiques pour cela. Celle que je connais est Sidux http://distrowatch.com/table.php?distribution=sidux qui est considérée comme étant une "rolling release", puisque basée sur Debian testing.
                  Parfaite pour une machine personnelle.
                • [^] # Re: Venez aider à la sortie de Squeeze !

                  Posté par (page perso) . Évalué à 9.

                  Je tourne même avec une SID au boulot depuis 4 ans, je n'ai pas de souci. J'utilisais SID plusieurs années avant sur mes ordinateurs personnels sans souci non plus (à part le passage à XFree qui a été résolu le lendemain).

                  Bon, il m'est quand même arrivé d'avoir des petits soucis mineurs, mais rien d'embêtant pour un utilisateur un peu expérimenté. En tous cas, j'ai moins de problèmes qu'avec les distributions dites stables.
                  • [^] # Re: Venez aider à la sortie de Squeeze !

                    Posté par (page perso) . Évalué à 8.

                    mais rien d'embêtant pour un utilisateur un peu expérimenté

                    En effet, c'est tout le problème. Quand on est un peu expérimenté, Debian est une distribution formidable. Mais pour des novices, je préfère leur installer une Mandriva (de préférence avec une version sortie depuis quelques mois). Je passe environ 5 heures pour les mettre à l'aise sur leur machine et le résultat est excellent. Je pourrais obtenir le même résultat avec Debian mais je devrais consacrer beaucoup plus de temps à l'installation et au paramétrage alors que tout est fini en moins d'une heure avec Mandriva.

                    Debian, oui, c'est très bien mais il faut la réserver à des connaisseurs sous peine de déconvenues.
          • [^] # Re: Venez aider à la sortie de Squeeze !

            Posté par (page perso) . Évalué à 7.

            Je ne suis pas d'accord.

            Déja, tout le monde ne vise pas le grand public d'une part, certains ont d'autres priorités ( comme la cohérence de la distribution, l'avancé du logiciel libre ) qui sont parfois en contradiction avec des buts immédiats autres.

            Ensuite, je pense que vouloir que tout les distros fassent la même chose, c'est idiot, et en total opposition à la richesse qu'on trouve au sein du logiciel libre. Si Debian ne veut pas pousser le grand publique, c'est non seulement leur droit, mais en plus une démarche saine pour la diversité du libre au niveau des objectifs.
            • [^] # Re: Venez aider à la sortie de Squeeze !

              Posté par (page perso) . Évalué à 10.

              Est-ce que ne pas vouloir tout le temps les toutes dernières mises à jours est l'opposé d'être grand public ?
              Étant donné la fréquence de mises à jours de Windows, j'ai un doute.
              Il n'y a que les "power user" qui s'inquiètent d'avoir toujours les dernières versions. Le vrai grand public s'en fiche.
              • [^] # Re: Venez aiderà lasortie de Squeeze !

                Posté par . Évalué à 0.

                Le grand public se fout de mettre à jour pour obtenir des correctifs de bugs ou de sécurité. Par contre, avoir la dernière fonctionnalité de tel ou tel logiciel, moins.
            • [^] # Re: Venez aider à la sortie de Squeeze !

              Posté par . Évalué à 6.

              Pourquoi vous "grand public" serait forcément synonyme de "version super récente pas testée" ??

              Le grand public ne voudrait pas de logiciels un peu plus robustes quitte à avoir un petit poil de fonctions en moins (voir en plus pour GNOME :-)

              Debian via entre autres l'équipe pkg-games, les blends (versions dérivées Debian EDU, voir http://wiki.debian.org/DebianPureBlends), vise également le grand public, mais n'est peut-être pas prêt comme d'autres à des concessions sur le recul de test et donc la qualité, tout cela pour livrer des versions à la pointe potentiellement remplies de bugs pas encore connus (et ainsi arriver à voir des gens penser que Linux n'est pas plus stable que Windows, après avoir essayé *la distribution user-friendly*).
              • [^] # Re: Venez aider à la sortie de Squeeze !

                Posté par (page perso) . Évalué à 10.

                Je suis d'accord.
                Et je suis peut-être naïf, mais je ne vois pas le grave problème de sécurité à utiliser une vieille version de logiciel de navigation ou autre, du moment qu'on a les mises à jour mineures ?
                Au boulot, la plupart des postes sont encore en RHEL3 avec Firefox 1.5 et un vieux flash (9 je crois), tout le monde va encore sans problème sur le site de sa banque, les actualités ou autres résultats sportifs sans être bloqué ou se faire hameçonner à tour de bras...
                Un bureau Linux des années 2000 était déjà très utilisable et sécurisé (même pour des non informaticiens), rien ne sert de toujours courir en avant poussé par je ne sais quelle peur panique de ne pas être à la page ?
                Bref, moi j'aime bien Debian stable.
              • [^] # Re: Venez aider à la sortie de Squeeze !

                Posté par . Évalué à 9.

                Perso, l'expression «grand public» m'horripile au plus haut point. Si c'est une entité, l'a-t'on déjà sondée avant de tirer des conclusions en-veux-tu-en-voilà?
      • [^] # Re: Venez aider à la sortie de Squeeze !

        Posté par . Évalué à 4.

        Question naïve, histoire de comprendre.

        Qu'est-ce qui est attendu avant de déclarer stable une branche ? Assez de retour utilisateurs pour vérifier la stabilité ? La baisse de fréquence des mises à jour de sécurité ?
  • # Abando du freeze à date fixe ?

    Posté par . Évalué à 2.

    On n'est pas en décembre, 2010 semble être une année paire.

    Sait-on si c'est l'abandon du freeze à période fixe ou s'il est remis à plus tard ?


    On en avait parlé il y a à peu près un an http://linuxfr.org/2009/07/29/25776.html

    Il se prend pour Napoléon, son état empire.

    • [^] # Re: Abando du freeze à date fixe ?

      Posté par (page perso) . Évalué à 4.

      Il ne semble pas abandonné. À titre de transition, le gel de Squeeze était initialement prévu en janvier 2010. Ça a un peu dérivé, c'est tout.
    • [^] # Re: Abando du freeze à date fixe ?

      Posté par (page perso) . Évalué à 3.

      Le gèle à date fixe est conservé. Par contre le "quand c'est prêt" est aussi conservé, donc il y a un peu de retard (~7 mois), mais c'est mieux ainsi.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: Abando du freeze à date fixe ?

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

        Gni?
        C'est pas un choix multiple entre date fixe et quand c'est prêt, c'est un "ou exclusif", il faut choisir, la ça fait cul entre deux chaises.
        De plus, 7 mois ce n'est pas "un peu" de retard, c'est beaucoup de retard à la vitesse de l'informatique (c'est même une version de plus d'Ubuntu ;-), qui elle sort à date fixe).

        C'est mieux ainsi? Je ne le remet pas en cause, mais il ne faut alors pas dire "à date fixe".
        • [^] # Re: Abando du freeze à date fixe ?

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

          Le but est de sortir la nouvelle stable à date fixe, maintenant si tout n'est pas prêt, ils ne vont pas sortir la distribution à moitié terminée. C'est donc totalement complémentaire. On bosse pour finir à telle date, si, malgré tous nos efforts, c'est pas prêt on attend pour que ce soit prêt.

          Et 7 mois c'est rien au niveau de l'informatique qui n'a plus évolué depuis l'invention du HTTP, le protocole universel. On optimise juste le traitement du HTTP depuis. C'est pour ça qu'un distribution qui à déjà plusieurs années peut fonctionner comme serveur, il n'y a pas de vrai ajout technologique et les technologies existantes depuis longtemps sont toujours très mal supportée partout.

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

          • [^] # Re: Abando du freeze à date fixe ?

            Posté par (page perso) . Évalué à 0.

            Le but est de sortir la nouvelle stable à date fixe

            N'importe quoi. Il n'a jamais été question de sortir Debian à date fixe.

            Et 7 mois c'est rien au niveau de l'informatique qui n'a plus évolué depuis l'invention du HTTP, le protocole universel.

            Tout ce message est du second degré ?
            • [^] # Re: Abando du freeze à date fixe ?

              Posté par (page perso) . Évalué à 3.

              oui le freeze, le freeze ... j'ai fourché. Ça ne change rien non plus.

              Tout ce message est du second degré ?
              Non. Mais tu vas certainement me présenter des technologies totalement nouvelles disponibles pour les utilisateurs.

              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # Petite correction pour la version de KDE

    Posté par . Évalué à 3.

    Bonsoir

    juste une petite correction c'est KDE 4.4.5

    New features of the upcoming release include:
    State of the art desktop environments, based on KDE 4.4.5, Gnome 2.30.0, LXDE 0.5.0, XFCE 4.6.2, X.org 7.5, OpenOffice.org 3.2.1 and many other applications.
    Stable and current versions of common server software such as Apache 2.2.16, PHP 5.3.2, MySQL 5.1.48, PostgreSQL 8.4.4 and Samba 3.4.
    Modern interpreters and compilers for all common languages such as Python 2.6 and 3.1, Perl 5.10, GHC 6.12 and GCC 4.4.
    DKMS, a framework to generate Linux kernel modules whose sources do not reside in the Linux kernel source tree.
    Dependency-based ordering of init scripts using insserv, allowing parallel execution to shorten the time needed to boot the system.

    @tte Thierry
    • [^] # Re: Petite correction pour la version de KDE

      Posté par . Évalué à -2.

      ils sont chanceux si KDE n'avait pas retarde d'une semaine 4.5 c'etait un peu has been leur "state of the art"... et vu les changements fait dans 4.5 en particulier au niveau des activites je trouve ca dommage qu'ils aient pas attendu une semaine au point ou ils en etaient...
      • [^] # Re: Petite correction pour la version de KDE

        Posté par (page perso) . Évalué à 4.

        Ils auraient dû attendre beaucoup plus d'une semaine. Les versions de KDE ne sont pas introduites en version x.y.0 mais plutôt .2 ou .3 (ils attendent qu'elles soit un peu testées), ça fait tout de suite plus long.

        « 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: Petite correction pour la version de KDE

          Posté par (page perso) . Évalué à 7.

          Et puis, en attendant une semaine par ci, une semaine par la, on se retrouve avec plusieurs semaines de retard.

          Et puis, faut arreter de déconner. Kde 4.4 est utilisable. Et je suis sur que si debian avait freezé avec kde 4.3, c'est celle que tu demanderais.
  • # Bad news

    Posté par . Évalué à 7.

    Moi je n'aime pas quand debian testing freeze, ça veut dire que je vais devoir utiliser plus de paquets venant de unstable pendant un moment avant que testing redevienne à nouveau testing.

    L'idéal ça serait que le freeze de testing ne bloque pas la distribution mais soit une sorte de fork avec des dépôts bien distincts. Moi j'aime bien testing parce que c'est une sorte de rolling release qui offre la sécurité d'avoir des paquets testé pendant quelques jours avant d'être intégré, ce qui fait qu'elle est tout a fait utilisable pour des utilisations de desktop ou de serveur perso sans risquer de tout voir tomber en panne à chaque dist-upgrade, et d'éviter de rester figer [troll]parfois dans la médiocrité[/troll].
  • # Des mises à jour et du grand public

    Posté par (page perso) . Évalué à 10.

    Pour ceux qui n'aiment pas voir une vieille version d'Iceweasel, de Pidgin et de Wormux, j'aimerais rappeler que :
    1. le grand public se moque d'avoir des logiciels récents, la preuve : Windows XP, Windows Internet Explorer 6 ;
    2. en revanche il ne se moque pas du tout d'avoir des logiciels qui marchent bien plutôt que des logiciels qui se plantent ;
    3. [http://www.backports.org] ;
    4. [http://volatile.debian.org].
    • [^] # Re: Des mises à jour et du grand public

      Posté par . Évalué à 7.

      Le 2 ne serait-il pas en contradiction avec les exemples donnés en 1 ?!?
      Parce que rien qu'IE6, sur le plan "des logiciels qui marchent bien", on repassera...
      • [^] # Re: Des mises à jour et du grand public

        Posté par . Évalué à 8.

        "un logiciel qui marche bien" dans ce contexte n'est qu'un logiciel qui :
        se lance quant on clique, toujours.
        permet l'utilisation du service, toujours.
        ne perds pas les données utilisateurs, jamais.

        Pour le reste : les problèmes de sécurité du logiciel et ses conséquences, ben c'est de la sécurité, ce truc "ha oui faut faire gaffe en allant sur sa banque". Les problèmes de vie privée : "bah j'ai pas grand chose à cacher". Les plantages, quels que soient les raisons : "bah c'est pas grave je relance, ça marche. Au pire, je reboot."
    • [^] # Re: Des mises à jour et du grand public

      Posté par . Évalué à 2.

      Entièrement d'accord sur le principe!

      Mais je dirais de faire attention aux détails:
      Quand MSN change subrepticement son protocole pour améliorer l'expérience utilisateur faire chier les clients alternatifs, il faut pouvoir réagir rapidement, et mettre à jour rapidement.

      Et ce n'est pas un problème de sécurité, donc il faut bien au moins les backports.
      Mais ce n'est pas incompatible avec tes propos: stable+backports, en faisant attention à ne pas laisser le dépôt backports se transformer en testing...
      • [^] # Re: Des mises à jour et du grand public

        Posté par (page perso) . Évalué à 6.

        Quand MSN change subrepticement son protocole pour faire chier les clients alternatifs, il faut pouvoir réagir rapidement, et mettre à jour rapidement.

        Il faudrait surtout se libérer de la dépendance intégrale à une société qui fait ce qu'elle veut de son service.

        Et ce n'est pas un problème de sécurité, donc il faut bien au moins les backports.

        Non, les volatils. [http://volatile.debian.org/].
        • [^] # Re: Des mises à jour et du grand public

          Posté par (page perso) . Évalué à 5.

          oué enfin ce serait un projet open source qui changerait de protocole du jour au lendemain ça ne changerait pas grand chose au problème (au mieux ce sera un peu plus facile)
          • [^] # Re: Des mises à jour et du grand public

            Posté par (page perso) . Évalué à 0.

            Et si c'était un protocole standard publié par l'IETF, genre ?
            • [^] # Re: Des mises à jour et du grand public

              Posté par (page perso) . Évalué à 5.

              c'est pas le sujet, tu dévies le problème pour conforter ton opinion
              Si c'est un protocole standard qui ne change pas alors il n'y a pas de problème lorsqu'il change puisque ça n'arrive pas.
              Mais ça on s'en fout dans la discution

              Si on a MSN qui change de protocole il faut mettre à jour les clients et ça pue.
              Si je fait un soft de IM avec un protocole et qu'il change ... ben c'est pareil, faut mettre les clients à jour et ça pue, le fait que ce soit libre facilite les choses mais ne résout pas le problème.
              Si j'utilise par exemple un truc pas standard (pas officiel, un draft ou un truc du genre) pour faire de la vidéo sur jabber par exemple. Imaginons que je l'utilise dans un serveur libre, et un client libre.
              Si le serveur change de protocole sans avertir quiconque, ben je suis dans la même merde que si j'avais msn, le temps de mettre à jour le client, et le temps qu'il n'arrivera jamais dans stable.
              • [^] # Re: Des mises à jour et du grand public

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

                Si je fait un soft de IM avec un protocole et qu'il change ... ben c'est pareil, faut mettre les clients à jour et ça pue, le fait que ce soit libre facilite les choses mais ne résout pas le problème.

                Si le projet est bien gérer, il prévient à l'avance du changement et on peut agir en conséquence. MS attend que les clients supportant le nouveau protocole de MSN soient suffisamment utilisés avant de changer le protocole côté serveur, ce n'est juste pas visible de notre côté. Les autres softs d'IM doivent faire pareil pour que les utilisateurs aient le temps de s'adapter.

                « 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: Des mises à jour et du grand public

                  Posté par (page perso) . Évalué à 3.

                  Oui, c'est bien pour ça que ça réagissait par rapport à Quand MSN change subrepticement son protocole et donc au fait que ça change sans prévenir.

                  Evidemment, si les changements sont prévenus à l'avance, si c'est bien fait il y a plus de chance pour que ça passe bien.
                  Mais encore une fois c'est pas lié au libre, si j'ai un soft proprio de serveur d'IM et que je préviens que je vais changer de protocole, les clients peuvent changer.

                  Ce qui a du mal à être compris on dirait c'est que je réagissais sur le lien protocole de MSN qui change -> normal c'est MS c'est proprio donc ça pue

                  D'ailleurs, on voit bien que même dans le libre, même en prévenant ce qui coince, ça ne marche pas non plus -> http://linuxfr.org/comments/1150952.html#1150952
                  (pour ceux qui ne veulent pas lire, wormux debian est avec une version de protocole incompatible avec les versions actuelles...)
                  • [^] # Re: Des mises à jour et du grand public

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

                    Ce qui a du mal à être compris on dirait c'est que je réagissais sur le lien protocole de MSN qui change -> normal c'est MS c'est proprio donc ça pue

                    Le changement ne peut se faire sans prévenir que lorsque toute la chaine serveur et client est maitrisée par la même personne (ou un groupe limité) ce qui est très difficile avec le logiciel libre.

                    D'ailleurs, on voit bien que même dans le libre, même en prévenant ce qui coince, ça ne marche pas non plus -> http://linuxfr.org/comments/1150952.html#1150952
                    (pour ceux qui ne veulent pas lire, wormux debian est avec une version de protocole incompatible avec les versions actuelles...)


                    Mais ça n'a pas changer du jour au lendemain, ça fait plus de 6 mois que la 0.9.0 est sortie et qu'il n'y a toujours rien du côté de Debian.

                    « 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: Des mises à jour et du grand public

                      Posté par . Évalué à 5.

                      ah, c'est pas une version 1.0 ou plus ? c'est toujours en cours de développement en fait ?

                      qu'est-ce que vous nous pétez les glaouis alors ?
                      • [^] # Re: Des mises à jour et du grand public

                        Posté par . Évalué à 3.

                        Tu veux vraiment qu'on enlève tous les logiciels avec un numéro de version < 1.0 ?

                        Je te laisse essayer de démarrer en enlevant tout ça...
                        • [^] # Re: Des mises à jour et du grand public

                          Posté par . Évalué à 3.

                          on a aussi le "droit" de supprimer les fs et leur dérivé si ils ont une release < 1.0 ?
                          ext2 apuuuu :P
                          • [^] # Re: Des mises à jour et du grand public

                            Posté par (page perso) . Évalué à 3.

                            Je me questionne à propos de ma modeste personne. Vu les défauts que je me traîne, je suis probablement en version 0.x

                            Et ne rigolez pas: si vous moulez, vous êtes probablement dans le même cas :-)
                            • [^] # Re: Des mises à jour et du grand public

                              Posté par . Évalué à 4.

                              nan mais sérieusement, l'API reseau est pas stable, et l'équipe de wormux ne veut supporter que deux versions, si j'ai bien lu plus bas : 0.9.1 et 0.9.2. les versions du protocole d'avant 0.5.x peuvent crever.

                              est-ce qu'un logiciel de ce type a sa place dans Debian ? il est pas fini, ce truc, il est pas totalement démoulé.

                              ou bien, que faire des utilisateurs Debian qui ont pris une version 0.5 ? il faut les parquer dans leur coin, dans une réserve ?

                              on a le même problème avec pleins d'autres logiciels, des fois on s'en fout des fois c'est juste génant des fois c'est des trous de sécurité béants ou des softs inutilisables (obsolètes comme ici), vous avez des solutions compatibles avec le fonctionnement de Debian et autres distributions qui ne forcent pas une réinstallation tous les 6 mois ?
                  • [^] # Re: Des mises à jour et du grand public

                    Posté par . Évalué à 3.

                    Bon, reprenons:

                    -De quoi on parle?
                    De la facilité d'utiliser une Debian stable par le grand public.

                    -Arguments en faveur d'une stable sachant que les applications vont devenir "obsolètes"
                    La plupart des utilisateurs "lambda" ne sont de toute façon pas au courant qu'une nouvelle version est sortie, et peut-être même ignorent-ils nombre de possibilités avec l'existante, la mise-à-jour continue n'est donc pas forcément un requis absolu.

                    -Pourquoi je dis que ça peut coincer dans certains cas
                    Parce qu'une application "obsolète" n'est pas forcément une application à laquelle il manque les fonctionnalités des toutes dernières versions, mais elle peut PERDRE des fonctionnalités.
                    Je cite MSN parce qu'on parle de Pidgin (et si Pidgin n'est utilisé que pour le protocole XMPP, euh... pourquoi Pidgin alors??), mais aussi parce que le grand public, il s'en fout un peu de savoir que XMPP marche toujours et qu'il peut communiquer avec des milliers des centaines de geeks informaticiens dans le Monde, il veut pouvoir faire ce qu'il fait avec un ordinateur d'habitude, et le changement pourra toujours venir plus tard.

                    Donc, MSN, c'est mal. Mais pour le grand-public, on ne peut pas l'enterrer d'un coup, c'est utopique et ce serait un frein à la progression de GNU/Linux.
                    • [^] # Re: Des mises à jour et du grand public

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

                      Parce qu'une application "obsolète" n'est pas forcément une application à laquelle il manque les fonctionnalités des toutes dernières versions, mais elle peut PERDRE des fonctionnalités.

                      Debian utilise deux mécanismes pour se prémunir contre les pertes de fonctionnalités :
                      - les « backports »,
                      - et le dépôt « volatile ».

                      « Backports » est comme son nom l'indique le dépôt par lequel sont disponibles des rétro-portages, c'est à dire des versions mises à jour des logiciels mais compilées pour la version stable de la distribution. Bien sûr, ils n'ont pas vocation à mettre à jours toutes les applications de la distribution stable chez tout le monde, sinon autant passer en testing, mais ils permettent de pallier au problème que tu évoques avec l'évolution des programmes ou de l'état de l'art (évolution des protocoles, OO qui n'arrive plus à ouvrir les documents pourris du dernier format MS, etc).

                      Plus fin que ça, quand il est prévisible que le programme aura une évolution plus rapide que le cycle de vie de la distribution stable, il y a aussi « volatile ». C'est là dedans que tu trouveras par exemple les paquetages de ClamAV, puisque pour ne pas perdre en efficacité un antivirus doit pouvoir mettre à jour les signatures de virus et son moteur.

                      Avec ces deux solutions, il y a de quoi vivre de manière stable sans perdre de fonctionnalité. Alors, heureux ?
                      • [^] # Re: Des mises à jour et du grand public

                        Posté par (page perso) . Évalué à 3.

                        Attention quand même : les paquets volatils, c'est officiel et pris en charge. Les paquets rétro-portés, non.
                      • [^] # Re: Des mises à jour et du grand public

                        Posté par . Évalué à 3.

                        Le problème que je vois dans les backports, c'est que pour l'instant, dû au public qui utilise Debian stable, les backports sont faits des façon raisonnable, mais qui s'occupe de la "modération"?
                        On choisit Debian Stable en connaissance de cause, pas pour avoir des mise à jours toutes les semaines.

                        Si tout le monde se met à utiliser Debian stable parce que "c'est plus facile pour les débutants", et que de nombreux utilisateurs veulent savoir pourquoi le Pidgin de leur petits-neveux clignote plus que le leur (enfin, non, j'espère que ça ça n'arrivera jamais, mais c'est pour l'exemple!), alors ils veulent le dernier Pidgin dans les backports.

                        Ensuite, c'est pour ouvrir la dernière version de .doc, bon, ok!

                        Ensuite, c'est parce que la fonction tellement mieux du dernier Amarok et teeeeellement incontournable, qu'on l'a fait quand même, pis la version KDE de stable elle est vraiment trop vieille, on peut faire quelquechose.

                        Et un jour on se rend compte que les 2/3 de testing sont en fait déjà dans les backports, et du coup pourquoi on les différencie déjà?
                        • [^] # Re: Des mises à jour et du grand public

                          Posté par (page perso) . Évalué à 3.

                          c'est parce que la fonction tellement mieux du dernier Amarok et teeeeellement incontournable

                          Là tu sors carrément du cadre de ma réponse :-). je disais juste qu'avec « volatile » (et dans une moindre mesure « backports » le support officiel en moins), il est tout à fait possible de vivre une expérience stable sans perte de fonctionnalité.

                          Ceux qui veulent un Pidgin qui clignote plus que celui du fils de la voisine au point d'envisager de changer de version de leur logiciel veulent par définition de l'instable.

                          Et un jour on se rend compte que les 2/3 de testing sont en fait déjà dans les backports, et du coup pourquoi on les différencie déjà?

                          Parce-que comme ça a été souligne plus haut les rétro-portages ne sont pas supportés officiellement, donc pas non plus de support de sécurité. Au-delà de ça, les versions des logiciels sont chaque fois rétro-portées pour la distribution stable et diffèrent donc de ceux de « testing », dépôt dans lequel ils s'intègrent avec la distribution qui a évolué aussi. Donc les rétro-portages ne servent bien qu'à récupérer une version plus à jour d'un programme précis qui répond à un besoin particulier, et non à faire la course à la nouveauté.

                          D'ailleurs avec l'absence de support officiel, comme chaque programme est fait pour s'intégrer à la distribution stable, plusieurs programmes rétro-portés peuvent mal fonctionner ensemble.
              • [^] # Re: Des mises à jour et du grand public

                Posté par . Évalué à 1.

                Tu oublies une chose, c'est que l'écosystème Linux sépare massivement logiciels et bibliothèques.
                Ce qui fait que pour implémenter la nouvelle version d'un protocole, deux choix sont possibles : soit elle conserve la compatibilité, et dans ce cas on peut se contenter de mettre à jour la bibliothèque, soit elle la casse, et on peut l'installer en parallèle de la précédente, ce que permettent tous les bons gestionnaires de paquets.

                C'est bien pour ça que l'ancien Gaim a été splitté en Pidgin (le client) et Purple (la bibliothèque) : ça leur permet d'être relativement indépendants et Purple peut être utilisée par d'autres (comme Telepathy).

                Quand bien même, ton scénario reste très peu probable.
                Le libre utilise principalement des formats et des protocoles ouverts et standardisés, ce qui fait qu'avant qu'un protocole soit modifié en cassant la compatibilité, ça doit être mûrement discuté, réfléchi et surtout accepté, puis ça doit être publié et les clients peuvent enfin l'implémenter.

                Alors avant qu'un client ayant besoin d'une nouvelle version d'un protocole, la distribution a le temps de voir venir.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Des mises à jour et du grand public

                  Posté par (page perso) . Évalué à 3.

                  Sur le _principe_ je suis d'accord. Dans les faits, pas totalement.
                  Déjà, concernant la séparation avec les libs, pourquoi pas, mais en réalité on se retrouve tout de même très souvent à devoir mettre à jour l'un lorsqu'on met à jour l'autre (la séparation est assez rare, tout du moins pour les applis desktop, pour les parties plus basses ça fonctionne mieux). Mais reste que ça c'est pas non plus l'apanage des projets libres.

                  Ensuite, sur la partie c'est libre donc on papote toussa ... heu, oui mais pas toujours, et surtout on peut papoter tant qu'on veut, lorsqu'une distrib sort avec des softs d'il y a presque un an ben c'est cool mais les dev upstream peuvent faire ce qu'ils veulent c'est la merde.
                  Et d'ailleurs il y a aussi plétore de softs (plus ou moins important) libre qui sont gérés par un très petit groupe voir une personne et donc qui peuvent faire ceci.
                  Bon ok, ça fini souvent tôt ou tard en fork, mais pas toujours ;)

                  Il suffit de regarder l'histoire de nagios, ou un groupe central le gère. S'ils le voulaient, ils pourraient très bien modifier le protocole rapidement, et les autres softs liés auraient probablement du mal à suivre. Mais oui, le côté libre facilite quand même car rien n'empêche de forker et de remettre la compatibilité par exemple, mais c'est lourd.
    • [^] # Re: Des mises à jour et du grand public

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

      2. en revanche il ne se moque pas du tout d'avoir des logiciels qui marchent bien plutôt que des logiciels qui se plantent ;

      Le problème pour Wormux, c'est que le protocole du jeu en réseau a changé et que les utilisateurs de Debian ne peuvent donc plus jouer qu'entre eux et ne peuvent pas se connecter aux serveurs de jeu. Donc ça ne marche 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: Des mises à jour et du grand public

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

        es utilisateurs de Debian ne peuvent donc plus jouer qu'entre eux et ne peuvent pas se connecter aux serveurs de jeu. Donc ça ne marche pas.

        bin si, sur http://faq.tuxfamily.org/Games/Fr ;-) sachant que s'il y avait un mainteneur du serveur de jeu, il pourrait y avoir les deux versions ;-) (sur un port différent au besoin).
        Pour wesnoth, un des développeurs y arrive bien (alors qu'il ne parle qu'anglais), maintenir la version stable et la version en développement pour un plus petit nombre, c'est une question de motivation (le shell est directement accessible avec possibilité de recompiler, de lancer ce qu'on veut, tant que vous restez joignables dans la durée sur le chan, tout le monde est le bienvenu pour proposer son serveur de jeu préféré).
        Nous proposons aussi un miroir pour les téléchargements à qui le souhaite, à regarder les stats de openarena http://stats.download.tuxfamily.org/openarena/ 60 Go par jour ne nous fait pas peur, qui veut faire mieux pour le libre ?
      • [^] # Re: Des mises à jour et du grand public

        Posté par . Évalué à 3.

        Le protocole de Wormux n'a pas vraiment changé. Simplement, nous ne pouvons autoriser des versions différentes à jouer ensemble.

        La communauté de joueurs étant petite, supporter des multiples versions ne feraient que la diminuer. Nous limitons volontairement les versions "supportées" à 2 ou 3. Actuellement, sont supportées les versions 0.9.1 et 0.9.2.

        Le problème de la mise à jour des logiciels ne se pose pas que pour les logiciels qui communique en réseau. La cohabitation OpenOffice.org 2.x vs 3.x était délicate il y a quelques temps. J'ai eu l'occasion de devoir mettre à jour un document OOo 3 sur une distrib qui n'avait que OOo 2, j'ai été obligé de prendre la version sur le site officiel, et l'installation ne s'est pas passée correctement, il a fallu bidouiller un peu...
  • # Bogues critiques restants

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

    Quels décomptes des bogues critiques ?

    La page Unofficial RC-Bugs Count [0] est clairement plus avantageuse avec 318 bogues ouvert que la version officielle avec 546 bogues [1].

    J'ai tendance à penser que le décompte non-officiel est plus précis, cette liste est proposée par l'équipe de publication de Debian pour celles et ceux qui cherchent un bogue à corriger.

    Dans tous les cas, longue vie à Debian et merci à toute la communauté autour du projet Debian pour le travail fourni jusque là. Maintenant, à nous de jouer, comme disait un président outre atlantique et en réponse aux commentaires précédents Vous qui, comme moi, êtes d'heureux utilisateurs de Debian, ne vous demandez pas ce que Debian peut faire pour vous, mais demandez-vous ce que vous pouvez faire pour Debian. ;)

    [0] http://bts.turmzimmer.net/details.php?bydist=squeeze
    [1] http://bugs.debian.org/release-critical/
  • # L'éternel dilemme... Bordel, il faut vraiment faire quelquechose !

    Posté par . Évalué à 8.

    On en revient toujours (moi le premier :p) à ce perpétuel dilemme : distro à jour ou distro stable ?

    Malheureusement, il me semble que ce n'est pas si simple que ça, car...

    1) souvent des vieilles versions de softs qui peuvent avoir été jugées stables peuvent être sous-optimisées, mal supporter tel ou tel protocole, voire planter quand confrontées à des conditions non prévues à la base. Je crois que dans tous ces cas, ce ne sera pas corrigé dans les dépôts stables -- il faut que je bug soit critique ou mette en cause la sécurité, non ?

    2) les backports, mille fois oui, mais quand les dépendances elles-mêmes évoluent, ça peut devenir problématique, d'une part ; et je ne sais pas ce qu'il en est réellement, mais en tout cas sous Ubuntu, les backports sont très peu fournis. On finit alors (sous Ubuntu, même une LTS) par mettre des PPA dans tous les sens :-/

    3) comparer une Debian stable à XP. Pourquoi pas. Sauf que, me semble-t-il, la base (API, bibliothèque standard, tout ça) d'un système Windows évolue très peu et que donc, on peut utiliser une appli récente sur un vieux système, souvent. Alors que sous Linux cela impliquera de mettre à jour des pans entiers de l'OS...

    4) dans la pratique, j'ai déjà du mal à attendre la nouvelle Ubuntu tous les 6 mois (qui certes, présente souvent pas mal de nouveaux bugs -- la LTS actuelle en a encore qquns qui semblent vraiment "triviaux" comme ça, vu de loin, mais qui des mois après ne sont pas encore corrigés)... Le pb, c'est que nos OS ont souvent des lacunes qui font qu'on veut avoir des versions récentes. Car pour un certain nb de choses on court après les softs windows (ne serait-ce que pour une meilleure interopérabilité). Donc si on cumule le retard intrinsèque des softs Linux au retard artificiel dû au cycle de release... :'( + le retard dans le développements des drivers...

    5) souvent, une nouvelle version d'un soft est plus stable, globalement ! Garder une vieille version, cumule alors tous les inconvénients...

    Bref, j'ai pas vraiment de solution. Je reste partisan d'un OS le + stable possible avec des backports les mieux fournis possibles (euh, c'est le cas de tout le monde non ?). Mais, il faut du monde pour maintenir tout ça. On voit qu'avec l'éparpillement, sous chaque release d'ubuntu, plein de bugs subsistent. Il faudrait selon moi moins de distros, moins de versions maintenues en simultané, mais vraiment bien maintenues.

    Il doit bien y avoir une solution ?

    Ces derniers temps, je commençais à installer des Ubuntu à des néophytes. Et puis je réalise, que, merde, tous les 6 mois, ils mettent leur système en péril (le moindre accroc et ils sont incapables de réparer). Merde, dans les applis les plus utilisées, reste des bugs rédhibitoires pour ces néophytes (le panel de Gnome avec des trucs superposés qui fait qu'on peut pas éteindre l'ordinateur (!), OO.org qui plante en boucle avec les boutons de la boite de restauration qui sont invisibles, ...)

    Et puis !! Il y a le problème des drivers ! Une distro stable qui ne supporte que du h/w sorti 2 ans avant, ça peut poser souci... Oh la la... Il suffirait d'un peu plus de coordination pour avoir quelque chose de terrible.
    • [^] # Re: L'éternel dilemme... Bordel, il faut vraiment faire quelquechose !

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

      Pour ton soucis si tes déjà sur un stade avancé, tu peu essayer des rolling release comme arch (assez technique quand même) ou frugalware... y en a d'autre, siddux basé sur debian stable, gentoo et j'en passe...
      • [^] # Re: L'éternel dilemme... Bordel, il faut vraiment faire quelquechose !

        Posté par . Évalué à 4.

        Merci seb pour ta réponse. En fait, personnellement, je me débrouille, ça ne m'embête pas plus que ça. Mais je pense à tous les utilisateurs qui voudraient tout simplement que ça marche. Et je voudrais pouvoir recommander l'esprit libre Linux à des gens, sans prier pour que ça continue de fonctionner. Car cela est un comble mais je trouve clairement un plus gros taux, dans mes connaissances, de personnes ayant des soucis avec Linux qu'avec Windows.

        Quant à Arch. C'est bien mais : ça requiert un certain travail ; on ne sait jamais trop si ce qu'on fait est optimal et si on n'oublie pas des trucs. Et SURTOUT, au final, j'avais une distro moins stable. Comme tout est à jour, certains composants sont plus ou moins stables, mais toujours. Puisque les composants peu matures le deviennent mais les composants matures repassent dans une version suivante peu mature... :-/ Ou alors, il faut ne mettre à jour que de manière sélective, et là c'est un encore plus gros travail...
    • [^] # Re: L'éternel dilemme... Bordel, il faut vraiment faire quelquechose !

      Posté par . Évalué à 4.

      Je suis tout a fait d'accord avec cette analyse. J'étais passé a Debian Lenny il y a un an, et j'avais décide de rester avec 100% des packages en mode stable pour avoir un système qui fonctionne vraiment. Je suis un utilisateur intensif de KVM, et j'ai eu des plantages très réguliers avec le noyau 2.6.26 de base. J'ai fini par tester une upgrade du noyau vers un 2.6.30-testing et c'était beaucoup mieux, mais pas encore parfait. Au final, je ne vois pas l'intérêt de rester de rester sur un système très ancien si ca n'apporte même pas une meilleure stabilité.

      Ce que je n'arrive vraiment pas a comprendre c'est la rigidité qui interdit les mises a jour des paquets "stables" dans debian: seuls les bugs majeurs sont corrigés. Cela veut dire qu'on ne bénéficie pas des nouvelles versions mineures d'un logiciel depuis la version upstream qui apporterait pourtant plus de stabilité avec un risque de régressions relativement faible. On reste donc avec plus de bugs au final.

      Je suis passé sous Fedora qui a l'approche opposée: les packages très souvent mis a jour. Un fort risque de régression, mais qui sera rapidement corrigé par une autre mise a jour si tel est le cas. En plus il y a une période de test avant qu'une mise a jour ne soit diffusée, donc on limite pas mal de régression de cette façon. Au final j'ai réussi a avoir un système assez stable et avec des packages très récents.

      Mais je crois que la stabilité ultime (qui dépend essentiellement du noyau) nécessite un noyau RHEL (Redhat Enterprise Linux). Je n'ai pas de souvenir d'un plantage sur les serveurs RHEL qu'on a au boulot et qui fonctionnent souvent de façon intensive. Ce qui me gêne chez Rhel/Centos c'est ne n'avoir qu'un choix très réduit de packages disponibles et d'avoir certaines options du noyau (comme reiserfs) qui sont désactivées. Il faudrait pouvoir combiner la stabilité d'un noyau RHEL avec un userspace plus fourni type Fedora/Debian.

      C'est pourquoi j'ai décidé de m'installer le noyau de la dernière RHEL6-beta2-refresh sur ma Fedora-13. Et ca fonctionne: il fabrique le initramfs avec dracut et on peut rebooter sans problème. On peut soit installer le RPM du kernel rhel6 simplement ou même recompiler ce noyau pour activer les options manquantes comme reiserrfs. Et je suis très content du résultat: le noyau est très stable (je pense qu'un noyau rhel6 beta est bien meilleur qu'un noyau debian/ubuntu dit stable), et mon système est très a jour.

      Je pense vraiment que la politique de rhel est la meilleure: on a toujours un noyau vraiment stable, et il y a des backports pour les drivers et les fonctionnalités importantes comme KVM que l'on peut avoir récemment dans rhel5. il n'y a pas de secret: il suffit de voir le nombre de patches des noyau rhel pour comprendre que c'est la conséquence d'un gros travail de maintenance qui est possible grâce aux nombreux développeurs dont ils disposent. Les noyaux des autres distributions reçoivent beaucoup moins d'attention et donc la qualité est aussi impactée.

      Ce n'est malheureusement pas toujours facile de combiner un noyau rhel sur une autre distribution. J'avais essayé avec un noyau rhel5, mais les modules que je voulais réactiver ne compilaient/fonctionnaient pas (ex: ntfs). C'est sans doute parce que le cœur du noyau avait reçu trop de modifications et qui ont rendu certains modules incompatibles, et ils ne s'en occupent pas car le module n'est pas utilisé dans le noyau rhel. Sinon il faut accepter de travailler uniquement avec les modules qui font partie de rhel. J'utilise encore reiserfs car c'est vraiment le meilleur pour les performances sur les petits fichiers en attendant que btrfs soit stable. Et sur le long terme cette combinaison ne fonctionne pas car il y a trop de différences entre la rhel et fedora (exemple: pas les mêmes outils pour fabriquer les images initrd/initramfs: mkinitrd et dracut). Mais dans la période actuelle, ca fonctionne plutôt bien.

      Si les distributions comme debian/ubuntu pouvaient fournir un noyau officiellement qui se base sur les sources rhel (comme centos) ca serait vraiment formidable et ca permettrait d'avoir le meilleur des deux mondes.
    • [^] # Re: L'éternel dilemme... Bordel, il faut vraiment faire quelquechose !

      Posté par . Évalué à 2.

      Le problème de la dispersion est un faux problème. Ce qu'il faut c'est réellement travailler de mèche avec les projets upstream et là on ne perd pas de travail.

      Pour ce qui est de la stabilité vs fonctionnalité. Moi je vois ça comme un curseur, tu le positionne où tu veut entre ces deux extrêmes. Pour moi actuellement le bon consensus c'est Debian testing.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # Une super nouvelle...avant de partir en vacance

    Posté par . Évalué à 2.

    Je ne l'esperais pas avant la rentrée.

    Ca c'est une bonne nouvelle. Encore quelques mois d'effort pour les développeurs et je pourrai réinstaller du stable sur les serveurs récents. J'ai du passer en Squeeze pour un contrôleur HDD qui n'était pas détecté par l'installateur de Lenny sur une nouvelle machine.

    Merci à tous les développeurs Debian pour leurs efforts !

Suivre le flux des commentaires

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