Journal une idée reçue vraiment ancrée

Posté par .
Tags : aucun
0
23
juil.
2006
Dans un climat de tension entre partisans de Debian et partisans d'Ubuntu, je souhaite rétablir la vérité sur un point qui est trop souvent reproché à Debian : son obsolescence.

Je lis trop souvent que les logiciels qui composent Debian ne sont pas adapté à un usage desktop et sont trop vieux. A cela la réponse habituelle est :

1- Utilisez Testing qui est généralement aussi stable que la plupart des distribution et tout autant à jour (si ce n'est plus parfois)
2- Utilisez des backports que vous pouvez trouver sur internet en restant en Stable. Les Backports sont des logiciels provenant d'une version plus récente de Debian compilés sur la version stable afin de ne pas avoir de conflits de dépendance vis à vis des bibliothèques.

Personnellement je reste en Stable et j'ai une autre méthode que je vais détailler ici : la compilation assistée à partir des sources. Debian propose de nombreux outils pour aider à la configuration et parmi eux ceux qui ont fait le succès de cette distribution sont apt-get et dpkg. Grâce à ces outils il est très facile de créer un paquet à partir des sources (proposées par Debian) d'une version plus récente d'un logiciels et avoir ainsi les logiciels qui vous intéressent dans leur version la plus récente.

Voici la marche à suivre pour créer vos propres Backports :

Le but de cette méthode est de faire ses propres backports (ainsi on est certain qu'ils respectent les sources et sont sécurisés).

Tout d'abord ajouter dans le /etc/apt/sources.list la ligne deb-src et l'adresse du repository de testing et/ou de unstable, puis taper dans un terminal :

apt-get source nomdulogiciel
cela va télécharger les sources et les décompresser dans le répertoire courant.
Ensuite il faut vérifier si le système qui va compiler les logiciels dispose de toutes les librairies nécessaires. Cela s'effectue facilement en tapant :
apt-get build-dep nomdulogiciel
et installer ce qui manque (en espérant que la version de stable est suffisante ou présente sinon il faut s'embêter à compiler la bibliothèque ce qui est un peu plus casse tête).
Une fois toutes les dépendances réglées, il suffit de taper :
dpkg-buildpackage
et cela va compiler. Vous allez vous retrouver avec un ou des .deb que vous pouvez installer avec la commande
dpkg -i lefichierenpointdeb

ou déposer dans un repository que vous aurez vous même créé (je vous invite à lire le manuel à ce sujet).

Je fais ceci sur un ordinateur que j'utilise en desktop et j'ai absolument tout ce que je souhaite. La seule contrainte étant qu'il faut vérifier soi-même que les logiciels n'ont pas une faille de sécurité à corriger. Cela démontre également l'intérêt de travailler avec des logiciels dont les sources sont fournis. Tout cela peut être automatisé par des scripts pour ceux que ça ennuierais de toujours devoir faire les mêmes actions. Quand à l'intérêt vis à vis d'une compilation "à la main" est le fait que ces paquets sont parfaitement intégré dans le gestionnaire de paquet et on peut donc les mettre à jour ou les supprimer plus aisément.
  • # ...

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

    Si c'est pour tout compiler autant utiliser une Gentoo :D.
    • [^] # Re: ...

      Posté par . Évalué à 8.

      Je suis d'accord que des distributions tel que Gentoo ou LFS sont très intéressantes mais d'un autre côté compiler tout n'est pas toujours très pertinent. J'ai oublié de préciser que les paquets compilé (une fois) sur un ordinateur peuvent ensuite être installé sur celui que l'on veut (le gain de temps est conséquent tout de même).

      Personnellement je compile mes paquets sur un ordinateur puissant et les transfère sur mon portable peu puissant qui mettrait un temps fou à les compiler. (C'est d'ailleurs pourquoi une distribution comme Debian qui propose des paquets précompilé était adéquate pour ce portable).

      Donc non, utiliser gentoo n'équivaut pas à cette méthode même si elle s'en rapproche. Je pensais même rajouter une phrase affirmant que si on le souhaitait on pouvait faire avec debian exactement ce que l'on fait avec Gentoo (install minimum puis compilation de tous les paquets)
      mais j'ai hésité en craignant qu'on me dise que dans gentoo c'était plus simple à faire.

      Je précise que j'apprécie particulièrement l'esprit de Gentoo (le fait de mettre autant en avant le code source) et son manuel qui m'a souvent servi. Avec Debian c'est ma distribution linux favorite.
      • [^] # Re: ...

        Posté par . Évalué à 2.

        Ce que tu dis dans le premier paragraphe (création de paquetage binaire est aussi faisable sur gentoo et très facilement aussi (quickpkg [ebuild] je crois). En revanche, c'est vrai que ça oblige quand même à tout compiler.
        Ensuite, c'est question de goût, personnellement, j'ai préféré gentoo (dont c'est vrai, la doc est particulièrement intéressante même pour les autres distributions).
        Par contre, je suis en train de penser que je vais sans doute me remettre à Debian pour faire des terminaux X sur des vieux oridinateur car cela me semble la distribution la mieux adapté à cela (à part peut-être slack, mais j'ai pas trop envie de me lancer dedans pour ça).
        Vous voyez d'autres candidats ?
        • [^] # Re: ...

          Posté par . Évalué à 3.

          Installer ltsp sur ta gentoo pour faire serveur de terminaux X ?
          • [^] # Re: ...

            Posté par . Évalué à 2.

            Merci beaucoup, je ne connaissait pas.
            Il y a même une doc sur gentoo :
            http://www.gentoo.org/doc/fr/ltsp.xml

            Je vais regarder ça avec attention

            J'ai testé xdmpc sur un "vieil" ordi 600 MHz, 128 de ram (mais je vais pouvoir tester avec un plus vieux) en le lancant sans disque dur mais avec une knoppix (kaella) que je lance ainsi
            knoppix 2 (ce qui lance sans X)
            puis X -query 192.168.0.1
            et bah ça tourne vraiment niquel parce qu'une fois lancé, le lecteur de cd ne tourne plus du tout car il a déjà chargé tout ce dont il a besoin dans la ram (faut que je vois à combien de ram je peux descendre avec cette technique).
  • # Re

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

    En meme temps ta manip marche aussi sur ubuntu.
    • [^] # Re: Re

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

      En même temps, sur les autres éditions, peut importe que ça soit possible ou non, tout est déjà a peu prêt à jour.
    • [^] # Re: Re

      Posté par . Évalué à -6.

      Bah normal ils ont pillé apt/dpkg sur debian
      • [^] # Re: Re

        Posté par . Évalué à 10.

        zont pas honte?
        Utiliser un outil libre.

        Ah les salauds, profiter de la premiere liberte offerte par la gpl, et pis des autres libertes aussi, on devrait pendre shuttleworth par les couilles.

        Les outils debian ne doivent etre utilise par que par debian!!! D'ailleurs on parle d'un changement del icence pour empecher ces keunards de chez booboontu d'utiliser leurs softs.
        • [^] # Re: Re

          Posté par . Évalué à 4.

          Oui euh j'ai pas dit que c'était pas bien, j'ai dit que faut pas dire << Ubuntu ils sont trop des bons codeurs, ils font même ce que Debian fait, tu vois ? >>, faut bien soutenir le fait que c'est normal que ça passe sous Ubuntu car c'est une Debian modifiée (à la base).

          Mais bon, maintenant si on peut plus rien dire contre le vénérable Ubuntu sans se faire rabattre par les GU (Gentils Ubuntiens).
          • [^] # Re: Re

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

            "j'ai pas dit que c'était pas bien"

            On a pas la même notion du mot piller alors ?
  • # Que reproche-t-on à sid ?

    Posté par . Évalué à 10.

    Je n'arriverai jamais à comprendre ce qu'on reproche à unstable dans Debian. Je l'utilise quotidiennement et je n'ai jamais eu aucun souci, et pourtant, j'ai vécu les dernières grosses transitions : C++, KDE 3.5, Xorg, python. Et tout a toujours bien fonctionné... J'ai des logiciels à la pointe sans aucun souci.

    Évidemment, je ne fais pas mes mises à jour comme un goret, je regarde ce que dist-upgrade m'enlève et si ça ne me plaît pas, je fais un simple upgrade en attendant que les paquets qui manquent pour que dist-upgrade passe sans encombre arrive. Ce n'est vraiment pas compliqué, ça prend 2 secondes pour regarder et pour prendre une décision. En plus, les développeurs Debian font suffisament bien leur boulot pour que ces transitions se passent très bien.

    Bref, unstable, c'est bien mangez-en si vous voulez des logiciels à jour avec un minimum de prise de tête.
    • [^] # Re: Que reproche-t-on à sid ?

      Posté par . Évalué à 5.

      Jusqu'au jour où tu te retrouves face à un paquet tout propre sur lui, mais qui a l'installation te fusille tout. Le mot "unstable" n'a pas été choisi par hasard. Ca ne signifie pas que ca va manger ton chat, mais que potentiellement, ca peut.

      Personnellement, j'appelle ca jouer à la roulette russe, et pas sur ma machine, merci.
      • [^] # Re: Que reproche-t-on à sid ?

        Posté par . Évalué à 4.

        qui a l'installation te fusille tout


        en sid depuis 2-3 ans, je n'ai jamais rien eu de "fusillé", même si je reconnais que parfois (rarement) c'est un peu "chaud" (la dernière fois étant le passage vers Xorg 7.0, mais je m'en suis sorti, le seul truc que je n'ai pu avoir de nouveau c'est xgl que je n'utilisais pas beaucoup de toute façon...)
        Au pire des cas on a un programme qui ne fonctionne pas bien quelques jours, et cela revient vite à la normale.

        En tout cas c'est sympa le truc pour les mises à jour à partir des sources, mais cela ne risque pas de poser problème avec les dépendances s'il y a des bibliotheques trop anciennes ?

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Que reproche-t-on à sid ?

          Posté par . Évalué à 2.

          Si ça me pose parfois des soucis avec certains logiciels (souvent les plus "gros" rarement les "petits") et le pire c'est nouvelles versions de logiciels debian (comme debhelper) dans ce cas là on est obligé de mettre à jour les librairies ou les logiciels incriminés avant en espérant que ça ne fasse pas boule de neige. Disons que ma méthode ne marche pas trop pour installer des logiciels avec des dépendances à rallonge qui utilisent les spécificité des nouvelles bibliothèques, mais marche parfaitement pour la plupart des autres.

          Je préconise cette méthode vraiment essentiellement si comme moi on est satisfait de Stable dans son ensemble et que ponctuellement on a besoin d'un programme qui est absent de Stable ou dont une mise à jour nous intéresse vraiment.
      • [^] # Re: Que reproche-t-on à sid ?

        Posté par . Évalué à 7.

        Ce qui me dissuade le plus d'aller en Unstable c'est le fait que les logiciels sont trop récent et n'ont pas eu le temps de faire leurs preuves. Je programme moi-même et les bugs que je détecte ne sont pas forcément ceux que les utilisateurs vont détecter. Je préfère que les logiciels soient un minimum éprouvé, c'est pourquoi testing est à mon avis bien plus interessante que unstable si l'on se place dans l'optique d'un usage de tous les jours.

        Utiliser une distribution testing ou unstable est clairement risqué, leur nom l'indique et on agit en connaissance de cause. Contrairement à Ubuntu que j'ai installé sur plusieurs postes de personnes novices qui ont quelques soucis de stabilité malgré le fait que ce soit une version dite stable (je parles d'ubuntu mais beaucoup d'autres distributions sont dans le même cas de figure). J'ai même eu plusieurs freeze complet de la machine avec impossibilité totale de killer X11 ou de passer sur un terminal virtuel.

        Quand à la personne plus haut qui évoque le fait que l'on puisse également faire la manip sous ubuntu, c'est normal, ils utilisent les outils debian. Ubuntu n'a à ma connaissance jamais été attaqué quand à l'obsolescence de ses logiciels (ce serait même plutôt l'inverse) alors que Debian si. Dans les fait on peut faire ce que l'on veut avec un système GNU/Linux et se limiter à juger une distribution à ce que l'on a à la fin de l'installation, a entrainé la surenchère de logiciels automatiquement installé dans leurs dernières versions pour que l'on dise "elle a tout ce qu'il faut". Ubuntu s'est écarté de ce travers avec leur choix d'interfaces unifiés mais a totalement succombé dans l'autre travers. Pour moi une installation de Ubuntu se classerrait entre Stable et Unstable (Testing ?). Ce qui ne veut pas dire que je les décrie (attention ce n'est pas un troll !) je la conseille même à mes amis pour débuter sous linux.

        Ce qui permet vraiment de juger une distribution ce sont ses outils spécifiques, pas la version de ses logiciels. Surtout si les outils en questions permettent d'installer des versions plus récente. Voilà ce que je voulais souligner.
        • [^] # Re: Que reproche-t-on à sid ?

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

          Ce qui me dissuade le plus d'aller en Unstable c'est le fait que les logiciels sont trop récent et n'ont pas eu le temps de faire leurs preuves.


          C'est exactement ce que je reproche le plus à Debian.
          Ici, "faire leurs preuves" veut dire "être débuggés par les autres distributions".
          Alors forcément ensuite c'est facile de dire "On est super-stables", si tout le sale boulot est fait par les autres.
          Merci, Debian, de participer à améliorer le Logiciel Libre.
          • [^] # Re: Que reproche-t-on à sid ?

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

            C'est exactement ce que je reproche le plus à Debian.
            Ici, "faire leurs preuves" veut dire "être débuggés par les autres distributions".
            Alors forcément ensuite c'est facile de dire "On est super-stables", si tout le sale boulot est fait par les autres.


            Je n'ai pas compris, là : le debuggage est fait grâce aux distributions testing et unstable. Lorsqu'un bug est corrigé, il est censé être remonter en upstream, si le problème n'est pas spécifique Debian.
            Pourrais-tu m'expliquer ton point de vue un peu plus ?
            • [^] # Re: Que reproche-t-on à sid ?

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

              Ce que je veux dire, c'est que les logiciels récents ne sont pas exposés au public à part dans les distributions de test.
              Les distributions de test, c'est bien pour débugger les problèmes de la distribution (problèmes de dépendances, scripts d'install/desinstall, etc...) mais l'exposition n'est pas suffisante pour trouver efficacement les bugs des logiciels en eux-même.

              C'est un peu comme si on disait que les distributions Cooker de Mandriva et Rawhide de Red Hat permettaient de débugger les applications. C'est trop "interne".

              Je trouve de Debian a le beau rôle en incluant dans "stable" des applications "déjà éprouvées", et en affirmant sa stabilité après.
              Déjà éprouvées, oui, mais déjà éprouvées par les autres distributions. Alors certes c'est un choix tout à fait défendable, qui profite à une catégorie d'utilisateurs. Ce qui m'énerve c'est juste l'attitude des debianistes convaincus qui oublient un peu trop vite à quoi ils doivent en partie leur stabilité légendaire.
              • [^] # Re: Que reproche-t-on à sid ?

                Posté par . Évalué à 2.

                c'est vrai et faux.
                Vrai parce qu'effectivement, la stable n'arrive que longtemps après que les paquets aient été proposés dans leur première version officielle stable, et quils profitent donc de l'expérience acquise sur debian unstable/testing, ubuntu, distribs rpm et autres. D'un autre côté Redhat fait pareil pour ses distributions serveur, je fais pareil quand j'achète une voiture, ca ne me choque donc pas plus que ca.

                Faux parce que je ne pense pas que le ratio d'utilisation stable/sid aille dans le sens de stable. La seule stat que j'ai trouvée pour le moment est là ( http://popcon.debian.org/ ) et montre clairement que la version sid est la plus utilisée (trois fois plus que la stable). C'est biaisé en ce sens que tout le monde ne connaît pas cet utilitaire, en même temps, c'est grâce à lui que l'ordre d'importance des paquets est calculé (et donc leur CD dans l'innombrable ribambelle de galettes nécessaires à l'installation complète). Et les mainteneurs debian remontent bien leurs bugs upstream.
                • [^] # Re: Que reproche-t-on à sid ?

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

                  Plus de sid déployées que de stable ?? Alors là j'ai des doutes, beaucoup même. Je vois beaucoup de stables autour de moi, et très peu de sid. Les gens qui veulent des paquets plus récents et qui tiennent absolument à une base Debian utilisent Ubuntu maintenant, pas sid (en tout cas c'est que ce que je constate à mon niveau).

                  Quant à popcon, effectivement je pense que c'est trop biaisé pour en tirer des statistiques valables. L'outil est censé influencer le développement de la distrib, donc c'est normal qu'il soit beaucoup plus utilisé par les gens qui ont des versions de dével. En plus j'imagine que toutes les distribs à base Debian (je pense à Ubuntu là) se signalent en tant que testing/unstable.
                  Je vois pas trop comment avoir des stats fiables, peut-être en comparant les stats FTP entre une mise à jour de glibc en stable et une mise à jour de glibc en testing, mais là encore avec le jeu des mirroirs on est pas fiables.
                  • [^] # Re: Que reproche-t-on à sid ?

                    Posté par . Évalué à 2.

                    je pense qu'il y a encore plein de grosses feignasses comme moi qui n'ont pas envie de réinstaller un système et qui continuent à vivre sous sid/unstable ou testing. Et je n'ai vu ubuntu tourner que chez une personne, alors que les 3 autres linuxiens que je connais personnellement tournent sous sid.

                    Pour moi la différence entre les versions debian se fait surtout ressentir au niveau professionnel, ou les admins sont en général réticents à se farcir des mises-à-jour qui peuvent être complexes tout les jours (alors que la plupart des updates sécurité passent comme une lettre à la poste). Donc là, c'est plus vers la fin de cycle de la stable que les admins commencent parfois à passer leurs chers utilisateurs sous testing.

                    Par contre, je suis bien d'accord qu'il est assez difficile de se faire une idée des réelle de la distribution des utilisateurs sur les 3 versions, et que les mirroirs ne permettent pas de faire ce genre de stat sur les téléchargements. Je pense que ce baser sur des user-agent des mails envoyés à debian-user par exemple pourrait être plus fiable (en éliminant tout les UA bizarres, on doit pouvoir isoler les versions assez bien).
      • [^] # Re: Que reproche-t-on à sid ?

        Posté par . Évalué à 4.

        Les paquets, il y a des gens très bien pour les faire derrière, il n'arrive pas tout cuits comme ça. Et ces gens, ils font tout pour que leurs paquets ne "fusillent" rien parce qu'ils s'en servent aussi. Alors, je ne dis pas qu'il n'y a jamais d'erreur, mais en tout cas sur les paquets importants, les développeurs Debian sont suffisament expérimentés (et même parfois nombreux) pour que le taux d'erreur soit très très faible voire quasi nul.
        • [^] # Re: Que reproche-t-on à sid ?

          Posté par . Évalué à 4.

          C'est malheureusement plus facile à dire qu'à faire.
          Personnellement, j'ai souvenir d'une mise à jour de glibc sur la version "stable" d'une autre distribution qui a réellement flingué le système de plusieurs centaines d'utilisateurs. A priori, le mainteneur était aussi expérimenté et savait ce qu'il faisait (et en l'occurence ce n'etait pas son packaging qui etait en cause)...
          Le "chez moi ca marche" sur des paquets comme glibc, c'est rarement suffisant.

          C'est justement sur des paquets importants comme X ou glibc qu'il est très dur de tracer les régressions de ce type et que ca te plaise ou non, le but de unstable est bien d'essuyer les platres sur ce genre de mises à jour.
    • [^] # Re: Que reproche-t-on à sid ?

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

      Évidemment, je ne fais pas mes mises à jour comme un goret

      Parfois, même en faisant gaffe, t'as un paquet vérolé qui s'installe et personne n'avait encore reporté le bug. Donc toi tu te dis naivement, chouette, apt-listbug ne rale pas, allons y ! Puis là pouf, ta machine reboot plus, car le paquet discover est buggué.

      Certes, j'ai pu réparer depuis un liveCD grace à la MAJ qui est vite arrivée, mais si ce jour là j'avais eu besoin dans la minute de mon PC, j'etais cuis. Depuis, après chaque MAJ je reboot, pour voir si rien ne coince (car discover kan il est foireux tu t'en rend compte qu'au 1er reboot !) et mon laptop "boulot" est en testing.
      • [^] # Re: Que reproche-t-on à sid ?

        Posté par . Évalué à 0.

        Quand tu vois une mise à jour de discover, tu peux aussi refuser la mise à jour et attendre quelques jours pour voir si tout a fonctionné chez les autres si vraiment c'est vital... La question "Do you want to continue?", elle n'est pas là que pour faire beau. Ça fait aussi partie de "pas comme un goret".
    • [^] # Re: Que reproche-t-on à sid ?

      Posté par . Évalué à 0.

      J'ai arrêté de trouver un intérêt à debian depuis le jour où j'ai du réinstaller une bécanne lors des semaines où beaucoup trop de paquets KDE étaient cassés, A LA FOIS EN TESTING ET UNSTABLE.
      En plus, Testing a presque toujours des paquets qui se barrent et qui ne reviennent que longtemps après et on ne peut pas télécharger des jigdo de unstable pour faire des installes offline quand les mecs de debian se sont dit qu'ils vont casser un desktop pour plusieurs semaines.

      Quant au sujet du journal, duhh... tant qu'à compiler une nouvelle version du desktop sur sa vieille debian stable obsolète, autant installer une gentoo, car c'est justement le desktop et ses applis qui mettent du temps à compiler, les petits utilitaires, le kernel, ça prends pas de temps.
      • [^] # Re: Que reproche-t-on à sid ?

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

        Cassés comment ?
        Genre des paquets avaient été supprimés ?
        Genre il n'y avait aucun bug report ?
        • [^] # Re: Que reproche-t-on à sid ?

          Posté par . Évalué à 0.

          genre on a autre chose a foutre que de passer son temps a se palucher des bug reports tous les 4 matins.

          Que ta distrib' soit une fin en soi dans ton monde, tres bien, mais essaye de comprendre que pour beaucoup (y compris des informaticiens geek developpeurs comme moi), une distrib est un moyen et ont besoin que ca juste marche et sans avoir a se fader 2km de bug reports en anglais et determiner si oui ou non ca va l'impacter.

          Bref, l'immobilisme "c'est tres bien ca marche tres bien on change rien" comme tu le fais n'a jamais ete une tres bonne reaction face aux critiques construites comme on en voit.

          Ubuntu a un succes monstrueux, au lieu de te braquer contre la distrib a base de "les salauds d'encules d'en face, ils vont tuer debian", demande toi pourquoi ubuntu a du succes, ce qui fait sa valeur ajoutee etc.

          Ou alors enfonce toi la tete dans le sable comme tu le fais a chaque fois qu'on te fait remarquer un defaut dans l'utilisation quotidienne de la distrib.

          C'est toi qui choise, mais arretes de repeter a qui veut l'entendre (ou pas d'ailleurs) que debian est une distrib pour le desktop.
          • [^] # Re: Que reproche-t-on à sid ?

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

            genre on a autre chose a foutre que de passer son temps a se palucher des bug reports tous les 4 matins.

            Une demi-seconde le temps de voir si ce bug s'applique à moi et si le paquet est important, une fois toutes les deux ou trois semaines, c'est pas trop long encore.

            Que ta distrib' soit une fin en soi dans ton monde, tres bien, mais essaye de comprendre que pour beaucoup (y compris des informaticiens geek developpeurs comme moi), une distrib est un moyen et ont besoin que ca juste marche et sans avoir a se fader 2km de bug reports en anglais et determiner si oui ou non ca va l'impacter.

            Ou bien tu ne lis pas ce que j'écrit, ou bien tu le fais exprès parce que ça t'amuse. Je n'ai *jamais* dit que Debian était la solution universelle.
            Qu'il dise que ça lui prend trop de temps de faire attention à ce qu'il fait, pourquoi pas. Comme je te l'ai déjà expliqué, je ne suis pas sûr que ce soit le bon choix, mais l'argument est recevable.
            Qu'il dise que Sid est tout le temps cassé et que les paquets disparaîssent tout seul, là je ne suis pas d'accord.

            face aux critiques construites comme on en voit.

            Le commentaire auquel j'ai répondu n'a pas grand chose de construit.

            Ubuntu a un succes monstrueux, au lieu de te braquer contre la distrib a base de "les salauds d'encules d'en face, ils vont tuer debian", demande toi pourquoi ubuntu a du succes, ce qui fait sa valeur ajoutee etc.

            J'aimerai bien que tu cites un commentaire ou j'ai dit quelque chose de ce genre. Je me fiche du succès d'Ubuntu. Si des gens sont satisfaits avec cette distribution, tant mieux pour moi. Mais qu'on arrête de dire des choses *fausses* sur Debian.

            Ou alors enfonce toi la tete dans le sable comme tu le fais a chaque fois qu'on te fait remarquer un defaut dans l'utilisation quotidienne de la distrib.

            Je ne met pas la tête dans le sable, je dis que ces problèmes peuvent être éviter quand on fait attention, et qu'il y a des gens que ça ne dérange pas.
            Sid a pour moi l'avantage d'être plus à jour qu'Ubuntu (sans backports).

            C'est toi qui choise, mais arretes de repeter a qui veut l'entendre (ou pas d'ailleurs) que debian est une distrib pour le desktop.

            Donc je ne fais pas une utilisation de bureau de ma machine ? Surfer sur le net, écouter ma musique, regarder des vidéos, c'est quoi comme utilisation ?
        • [^] # Re: Que reproche-t-on à sid ?

          Posté par . Évalué à 1.

          Genre les anciens paquets ont été virés de testing, donc dans testing y'avait presque rien, et dans unstable y'avait des dépendances manquantes.

          Pas de "bug report", c'était une situation normale, je crois que c'était en rapport avec un changement d'ABI sur gcc mais je peux me gourrer. Ca a pris vachement trop de temps quand même alors je suis allé voir ailleurs et plus jamais je ne mettrais les pieds sur cette distrib, sauf s'ils sortent une stable pas obsolète et régulièrement.
          • [^] # Re: Que reproche-t-on à sid ?

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

            Genre les anciens paquets ont été virés de testing, donc dans testing y'avait presque rien, et dans unstable y'avait des dépendances manquantes.

            Donc quand apt te dit que tes paquets vont être supprimés, tu lui répond oui, et après tu te plains, ou bien j'ai rien compris ?
            • [^] # Re: Que reproche-t-on à sid ?

              Posté par . Évalué à 4.

              Tu pourrais ne pas lire les messages de travers, merci.
              Si tu avais VRAIMENT lu mon premier message tu saurais que j'ai fait face à ce problème quand j'ai dû reinstaller une debian sur une de mes bécannes, et que j'ai dû réinstaller la deb pendant cette période.

              Le choix se limitait donc à 3 solutions : passer en stable obsolète, passer en stable et backporter (c'est un no-no, je n'ai pas que ça à foutre de ma vie et perdre mon temps), changer de distribution.
              J'ai évidemment pris la 3eme solution.
              • [^] # Re: Que reproche-t-on à sid ?

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

                Tu pourrais ne pas lire les messages de travers, merci.
                Si tu avais VRAIMENT lu mon premier message tu saurais que j'ai fait face à ce problème quand j'ai dû reinstaller une debian sur une de mes bécannes, et que j'ai dû réinstaller la deb pendant cette période.


                Au temps pour moi, je te présente mes plus sincères excuses, j'ai effectivement lu trop vite.

                Le choix se limitait donc à 3 solutions : passer en stable obsolète, passer en stable et backporter (c'est un no-no, je n'ai pas que ça à foutre de ma vie et perdre mon temps), changer de distribution.
                J'ai évidemment pris la 3eme solution.


                Perdu :
                http://snapshot.debian.net
  • # logique de logicien

    Posté par . Évalué à 1.

    Toutes les distributions qui s'administrent au terminal sont obsolètes

    Debian se gère à la souris donc...

    Bon je comprends le ras-le-bol de certains de devoir passer par la case terminal pour configurer le moindre petit truc tout comme je comprend que certains préfèrent ce système.

    Perso quand j'administre des machines je bénis le terminal mais quand je ne suis plus qu'un Desktop user je maudis cet écran noir (l'impression de passer plus de temps à configurer qu'à réellement travailler)... Du reste c'est ce qui m'a fait passer de Slackware à Windows Ubuntu
  • # Je dis peut-être une bétise mais...

    Posté par . Évalué à 1.

    quelle diférence avec wget et dpkg sur le bon paquet si on ne modifie pas les sources?
    • [^] # Re: Je dis peut-être une bétise mais...

      Posté par . Évalué à 4.

      quelle diférence avec wget et dpkg sur le bon paquet si on ne modifie pas les sources?


      Si j'ai bien compris tu parles d'utiliser wget pour récupérer le logiciel sur le site officiel par exemple ?

      La différence entre wget et apt-get source est que apt-get va récupérer les sources et des patchs effectués par le mainteneur du paquet ainsi qu'une préconfiguration (que l'on peut modifier dans le fichier debian/rules. Ainsi lorsque l'on tape dpkg-buildpackage, tout s'effectue automatiquement. La création de paquets à partir du code source uniquement est un peu plus complexe, même si il existe un excellent logiciel qui se nomme checkinstall qui peut parfois rendre service si on a pas le temps de créer des paquets dans les règles de l'art et que l'on souhaite tout de même pouvoir désinstaller facilement le programme que l'on vient d'installer.
      • [^] # Re: Je dis peut-être une bétise mais...

        Posté par . Évalué à 1.

        non non récupéré le logiciel dans les dépôts de sid et l'installer tout bêtement
        • [^] # Re: Je dis peut-être une bétise mais...

          Posté par . Évalué à 2.

          non non récupéré le logiciel dans les dépôts de sid et l'installer tout bêtement


          Les bibliothèques avec lesquels le logiciel a été compilé et celles présente sur l'ordinateur ne correspondent pas forcément et du coup tu risque d'avoir des soucis. Il est possible de rajouter les repository de sid et d'installer ces paquets sur Stable, mais cela entraînerait de nombreuses mises à jours (bibliothèques) et risquent de casser les logiciels déjà installé. Autant passer à Sid oun Unstable totalement dans ce cas, ou utiliser les backports.
  • # Mais bien sur

    Posté par . Évalué à 7.

    et si on faisait un repository avec tous les paquets de sid bakportés pour stable ?
    Puis on ferait des wget des packages et des dpkg -i pour les installer.

    On pourrait l'appeller ... euh... sid ? ou sid-stable vu que ce sera basé sur une stable -_-
    • [^] # Re: Mais bien sur

      Posté par . Évalué à 2.

      on l'appelerait backports.org. Et ca marcherait vraiment bien. Et pi les sources, elles seraient pas mal. Mais bon, ya pas tout sid comme ca. C'est sans doute un petit peu dû au léger problème de taille d'archives tout ca...
      • [^] # Re: Mais bien sur

        Posté par . Évalué à 3.

        puis peut-être légèrement que gérer toutes les dépendances sur backports.org avec les sources de sid revient à résoudre les mêmes problèmes que ce que font les dev debian avec sid.

        Utiliser Sarge et backporter à tout va pour avoir une distribution "avec les dernières versions", c'est rien comprendre à Debian.
  • # Une idée reçue vraiment ancrée

    Posté par . Évalué à 9.

    Normal, tu l'as confirmé.
    Si debian était à jours, tu ne compilerais pas de programme.
    Tu es satisfait et là est l'essentiel.

    > Grâce à ces outils il est très facile de créer un paquet à partir des sources (proposées par Debian)

    Mouaip. Avec un tarball qui va bien pour rpm tu fais : rpmbuild -ta truc.tgz. Depuis un src.rpm tu fais : rpmbuild --rebuild truc.src.rpm.

    Ceux qui sont sous rpm sont comme ceux sous dpkg : Ils n'ont pas envis de se faire chier avec des tâches répétitives.

    > qui ont fait le succès de cette distribution sont apt-get et dpkg.

    La grosse grosse grosse différence entre apt-get/dpkg et yum|smartrpm|.../rpm est que ceux qui utilisent debian "s'obligent" à plonger dans la doc. Malheureusement ceux qui utilisent rpm lisent rarement la doc. J'ignore pourquoi car rpm est également fabuleux.

    Les aspects psychologiques doivent beaucoup jouer.
    Ca me fait penser à yum qui se fait systématiquement exploser ici ou sur slashdot. Pourtant yum est très très utilisé par les développeurs de redhat/fedora qui, ne l'oublions pas, ont conçu rpm. J'imagine qu'ils ont une vision assez précisent sur les gestionnaire de paquets. Ces développeurs qui l'utilisent principalement avec rawhide, ce qui n'est pas une mince affaire car c'est la branche de développement. Ces même développeurs qui ont décidé d'intégrer yum un peu partout : dans anaconda, dans pup pour remplacer up2date et dans pirut pour remplacer system-config-package (ce dernier étant notablement "pourri").
    De ce que je vois sur les forums, 99% des problèmes avec yum viennent de personnes qui n'ont pas lu la doc. En général ils mélangent des dépôts non compatibles et demande l'impossible à yum (comme installer un programme qui demande gnome 2.14 alors que yum n'a que gnome 2.12 à l'horizon, etc...).
    M'enfin, quand le problème atteint un forum, c'est déjà bien. La pluspart du temps, le "gus" va gueuler "yum ça sucks" sans donner la moyen explication. Explication qu'il ne peut donner car il a déjà virer le système d'exploitation avec lequel yum lui a posé des problèmes.
    Il y a aussi ceux qui ne veulent pas prendre en compte les choix techniques faits par yum. Yum contrôle tout. Donc il fait une transaction à blanc (ça coûte du temps, il faut l'entête complet des paquets), vérifie systématiquement si les dépôts n'ont pas été mis à jours par rapport au cache (ça prend encore du temps), les dépendances sont résolues par librpm (ça évite les doublons de code (source d'erreur) et controle très fin : donc nécessité d'avoir parfois la liste des fichiers et non uniquement les requires/provide et dont ça prend du temps). C'est un choix technique qui a ses mérites et ses défauts. Comme je ne mets pas à jour ma bécane toute les 10 minutes, sa lenteur ne me dérange pas.
    Autre choix "technique", yum ne downgrade jamais un paquet pour en installer un autre. Downgrader un paquet c'est peut-être retirer une correction de sécurité et donc yum a fait le choix de ne jamais le faire.

    Pour ceux qui utilisent yum et en sont satisfaits (d'ailleurs j'ai envis de dire que c'est uniquement ceux qui ne l'utilisent pas qui n'en sont pas satisfait), ça fait mal au coeur tout ces "yum ça pue".

    Quand un mec utilise apt-get et que ça ne marche pas comme il l'espérait, il pense qu'il a fait une erreur car apt-get a une grosse réputation et qu'il doit lire la doc. Quand un mec utilise yum et que ça ne marche pas comme il l'espérait, il pense que yum pue car il l'a lu sur slashdot.



    Pour en revenir au débat initial (distribution a sortie fréquente ou lente), c'est une question de contraintes (cas d'un serveur) ou de goût (cas d'une machine perso).

    Pour ma bécane, je préfère les distributions à sortie fréquente. J'aime voir les dernières évolutions de GNU/Linux dans me prendre la tête à compiler 50 paquets. Puis certaines évolution sont l'enfer à installer à la main. Certe, ça fait aussi du boulot d'installer une nouvelle distribution (je ne fais jamais de mise à jour de distribution, ça merde trop souvent). Avec un peu d'organisation, c'est l'affaire d'une journée (voire 2 journées exceptionnellement). Donc par an ça me prend en gros 2 jours.
    Il y a quelques années, je gardais les distributions longtemps car je pensais que ça bouffe trop de temps de changer de distribution (mise à jour). Ben avant je bouffais beaucoup de temps à compiler les derniers évolutions de tel ou tel programme et à suivre les corrections de sécurité. Finalement, même en ne considérant que le temps, je fais très bien de monter en version ma distribution 2 fois par ans maximum.

    Aujourd'hui, je n'ai que 5 paquets fait à la main (des modules noyaux principalement). Avant je pouvait en avoir une quarantaine.

    > 1- Utilisez Testing

    Pas d'accord, c'est pour les développeurs/testeurs et non les utilisateurs.

    > 2- Utilisez des backports que vous pouvez trouver sur internet

    D'accord. Du moins si le suivi des trous de sécurité est correct.

    > entre partisans de Debian et partisans d'Ubuntu

    Debian et Ubuntu n'ont pas les mêmes objectifs. Sûr que beaucoup utilisent les deux à la fois. Sûr qu'Ubuntu a "piquer" beaucoup d'utilisateurs et de développeurs de Debian (et d'autres). C'est comme ça dans le logiciel libre. Il n'y a pas de priviléges à l'ancienneté.
  • # ubuntu unstable.

    Posté par . Évalué à 1.

    je suis passé a ubuntu unstable depuis quelque temps. C'est voyez vous, vers le mois de juin. Le nom de la version s'appelle Dapper. Il me semblait qu'avec la version précédente j'avais moins de soucis. Actuellement, je plante regulierement.

    En fait, depuis que j'ai placé un petit ventilateur pour refroidir le disque installé dans un tiroir, il semble que de unstable, cette version soit passée à stable. C'est étrange, non :-)

    (pauvre disque dur) ...
    • [^] # Re: ubuntu unstable.

      Posté par . Évalué à 3.

      J'ai eu a peu pres le meme genre de probleme : j'avais des plantages reguliers de ma connexion internet (free), et ca me faisait pester sur la mediocre disponibilite des DNS de free, les temps de reconnexion vers leurs DSLAMs, ainsi que sur le fait que recevoir un coup de fil sur la freebox plantait la tele, la connexion internet, et le telephone bien sur. Tout ceci m'enervait au plus haut point jusqu'au jour (il y a 3 semaines) ou j'ai touche ma freebox et constate qu'elle etait -brulante-, normal car empilee juste entre la ps2 et le decodeur TNT, qui chauffent bien eux aussi. Apres un depilage de tout ce materiel, plus aucun probleme, j'en viens presque a me demander si mes problemes de connexion ne venaient pas de ca...
      • [^] # Re: ubuntu unstable.

        Posté par . Évalué à 2.

        moi, pour la Freebox, j'ai un petit support en bois qui eleve un peu le boitier. Ce qui permet une aeration naturelle ; elle ne chauffe presque pas. Ca marche plutot bien.

        L'electronique est vraiment sensible a la chaleur. Je pensais que ce serait plus tranché comme réponse. En fait pour lon cas, c'était assez mitigé.
        • [^] # Re: ubuntu unstable.

          Posté par . Évalué à 2.

          Moi, j'ai une freebox V2 : vu qu'elle est grosse comme une boite de chaussures (j'exagère...), et qu'il n'y a quasiment rien à l'intérieur, elle ne chauffe pas :-)
  • # Intéressant...

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

    Salut,

    Maintenant je suis sous Ubuntu Dapper Drake, mais auparavant j'étais sous Debian Testing.
    Ta solution de stable + source de testing + mécanisme de build automatique est des plus alléchantes. Je n'y avais pas pensé. Je crois que si je dois un jour revenir à Debian ou installer une Debian sur une nouvelle machine, je tenterais bien cette solution.
  • # backports

    Posté par . Évalué à 3.

    www.backports.org fait exactement cela : ils prennent les sources en testing et les compilent dans une stable.
    En plus :
    1. leur dépôt est séparé, il s'appelle stable-backport. Tu n'es pas obligé de récupérer tous les paquets backportés, seulement ceux qui t'intéressent ;
    2. certaines sources ont besoin de légères modification pour être compilables en stable (p.ex. dépendances trop fortes sur une version testing d'une bibliothèque alors que la version stable fonctionnerait bien ; emplacements de fichiers différents entre stable/testing, etc.).

    Donc : puisqu'ils font le boulot correctement (et mettent à jour), pourquoi le faire ?
    • [^] # Re: backports

      Posté par . Évalué à 1.

      - parce que tout les paquets ne sont pas backportés.
      - parce que tu veux pouvoir modifier un bug/patch avant que le backport ne soit fait (vu que les mainteneurs ne s'occupent de leur backport que quand ils ont "relativement" stabilisé la version unstable)

Suivre le flux des commentaires

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