Journal [Troll du vendredi] Mettre au même niveau la base des distributions stables en regard des logiciels utilisateurs est-il vraiment une bonne chose ?

Posté par .
Tags : aucun
35
29
août
2008
Je trouve que cela serait une bonne idée de séparer dans les distributions Linux, surtout dans l'optique d'une utilisation "desktop", la base du système de la base des logiciels utilisateur, pour en faire des développement séparés. En effet la base système (démarrage, shell, cups, python, perl, php, mysql etc) peut se permettre de rester figée plus longtemps que la base des logiciels courants de l'utilisateur (inkscape, firefox, blender etc.), ces derniers en revanche ont besoin d'être mis à jour souvent pour profiter des dernières améliorations ("release early, release often")

À ma connaissance aucune distribution ne le fait vraiment.

Dans le contexte d'une entreprise, mais parfois aussi d'un particulier, une fois que l'on a installé un système, on n'a pas forcément envie de le changer tous les ans, ni même tous les 2-3 ans. Exemple du système de base Windows ou Mac os X : il n'y a pas de nouvelles versions majeures tous les 4 matins, par contre les utilisateurs peuvent mettre à jour leurs logiciels relativement facilement, ils n'ont à regarder que la gamme compatible du logiciel : version Tiger et/ou Panther, version XP et/ou Vista.
Les mises à jour de sécurité sont faites au fil de l'eau, tandis que les logiciels fournis par le "vendeur", comme itunes, quicktime, sont également mis à jour au fur et à mesure.

Sous linux, hormis les paquets spécifiques à une distribution, souvent incompatibles (mais on peut tenter avec alien...) un paquet pour la version "instable" (donc récente) ne fonctionnera pas avec la version "stable". Et trop souvent, la version stable utilisée ne contiendra pas une mise à jour satisfaisante du logiciel. Je ne connais pas toutes les distributions, mais si on peut comprendre que la distribution ne mette pas à jour son système de base stable pour ne pas casser des applications existantes, en revanche on pourrait souhaiter (je me répète) avoir des versions récentes des applications de bureau, qui pourtant dépendent moins les unes des autres. Mettre à jour OpenOffice ne va pas casser Gimp... On pourrait éventuellement envisager l'utilisation de chroot pour encore plus compartimenter et sécuriser les logiciels fraîchement installés.

Un exemple concret : en mai 2006, j'installe sur un poste de travail, à mon boulot, une opensuse 10.1. Après diverses configuration, elle fonctionne pas trop mal, et par rapport aux besoins de l'utilisateur, il n'est plus nécessaire de toucher au système de base (l'imprimante est configurée une fois pour toute, l'accès nfs ou samba à des serveurs distants aussi, on l'utilise même comme serveur de sauvegarde avec rsync etc). Par contre c'est firefox 1.5 qui est livré, et sur certains sites, cette version trop vieille ne fonctionne pas de façon satisfaisante. On peut éventuellement télécharger (à l'époque) la version 2 sur le site de mozilla, mais qu'en est-il pour ceux qui ont des pc 64 bits, mozilla ne fournissant un binaire que pour 32 bits ? (si on l'utilise sur un poste 64 bits, il peut manquer des icônes, et il y a peut-être d'autres problèmes sous-jacents).

Idem pour les mises à jour OpenOffice, les nouvelles versions étant quand même plus fonctionnelles. Donc soit on s'embête pour les mises à jour (recompilation...), soit on garde des versions obsolètes. Ou soit on migre tout le système vers la version de la distribution, ce qui n'est pas très rationnel vu que toute la base fonctionne bien pour l'usage qu'on en a. C'est pourtant ce que j'ai fait dans cet exemple de l'opensuse, une mise à jour courant août, ce qui m'a fait beaucoup plus perdre de temps que si c'était une simple mise à jour de 2-3 logiciels spécifiques : au démarrage, j'ai eu droit à quelques gels d'écran, les configurations utilisateurs n'étaient plus les mêmes, les imprimantes avaient disparues (ennuyeux pour ce qui était sensé être une mise à jour...).

Je ne remets pas non plus en cause l'intérêt des paquets dans les distributions, c'est un service que j'apprécie et utilise beaucoup, mais à trop focaliser sur la globalité de la distribution à mon moment donné, cela a tendance à trop la figer dans un ensemble rapidement dépassé.

Un autre exemple : Le minimum, pour Firefox 3, sous Mac OSX c'est Tiger, sorti en avril 2005 (soit un an avant l'opensuse dont on parle). Pour Windows, c'est XP, sorti en 2001. Sur mon EeePC, acheté au début de l'année, le système xandros ne permet pas, facilement j'entends, d'installer Firefox 3, la version "Linux" du site de Mozilla, est incompatible (problèmes de dépendances). Cela pourrait peut-être changer ( http://www.blogeee.net/2008/08/26/les-prochains-eeepc-sous-l(...) ) mais en attendant, cela ne donne pas une superbe image de Linux auprès du grand public.

Aussi, dans nombre de cas, je suis obligé de compiler moi-même mes paquets avec une debian stable pour pouvoir les utiliser sur l'EeePC. D'ailleurs très souvent ces paquets compilent sans problème sur la debian stable, preuve que le système de base n'a pas forcément besoin de la toute dernière libc pour faire fonctionne des logiciels récents. Le concept de backports mériterait aussi d'être plus étendu (par exemple il n'y a pas de backport officiel de iceweasel 3 pour debian stable).

Je ne dis pas que Mac OSX ou Windows sont parfaits dans leurs conceptions, loin de là, mais, ces différents points mériteraient sans doute d'être améliorés sous linux.
  • # www.backports.org

    Posté par . Évalué à 10.

    Avec debian, on peut installer une stable et prendre certains packets de backports, c'est fait pour ca:
    You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in.
    Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. I recommend you to pick out single backports which fits your needs, and not to use all backports available here.
    • [^] # Re: www.backports.org

      Posté par . Évalué à 10.

      c'est pour cela que je disais que le concept de backports mériterait d'être plus développé.

      Pas d'inkscape, ni de iceweasel, ni de icedove (dernière version 1.5 dans stable, or la version courante de thunderbird c'est la 2.0.0.16 ), ni de gimp dans backports, or ces paquets me semble plutôt essentiels pour une utilisation de "bureau".

      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: www.backports.org

      Posté par . Évalué à 3.

      Le principe existe aussi avec mandriva depuis la 2007.0, dans les sources de la distribution pour chacune des sources principales main (officielle) contrib (communautaire) et non-free (officielle) il y a la variante release (qui ne change plus une fois la distrib sortie), une update avec les mises à jours de sécurité et corrections de bugs, une backport avec des versions plus récentes d'une certain nombre de logiciels raisonnablement testées pour la distribution et enfin la variante testing où vont les paquets en cours de préparation avant d'arriver dans la source backport.

      Par exemple, la source backport de la 2008.1 contient un firefox 3.0.1

      après il y a encore les sources non officielles comme PLF (la plus importante), SoS ou MDE.
      • [^] # Re: www.backports.org

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

        raisonnablement testées
        Néanmoins, le logiciel n'a généralement pas eu le temps d'avoir été testé sur Cooker et des problèmes peuvent subsister. (issu de [http://wiki.mandriva.com/fr/Backport]).

        En clair, il y a de grandes chances que cela casse tout et le diagnostic en sera d'autant plus difficile que tout le monde n'utilise pas backports, soit beaucoup moins de rapports d'anomalie (et moins de temps que sur cooker pour les corriger).

        L'inconvénient de backports est (encore actuellement) que _toutes_ les dépendances qui sont dans backports sont mises à jour sur un urpmi --auto-select :/
        En gros, backports ne serait actif _que_ pour installer une nouvelle version de inkscape, par exemple, cela me conviendrait. Là il faut l'activer pour un paquet spécifique à installer puis se rappeller de penser à le désactiver pour éviter de tirer tout ce qu'il y a dans backports.
        Perso, je préfère refaire mes rpmbuild -ba pour les paquets qui m'intéressent ou alors directement être en cooker, avec les soucis afférents assumés.

        Le projet Taster est là pour améliorer les choses via la communauté : ce qui arrive en testing ou les bugs demandant un peu plus d'analyse (ou de retours, le statut "NEEDINFO") peuvent être vus à plusieurs
        http://www.mandrivafr.org/trac/taster/ la présentation
        http://forum.mandriva.com/viewforum.php?f=172 forum taster
        • [^] # Re: www.backports.org

          Posté par . Évalué à 2.

          En gros, backports ne serait actif _que_ pour installer une nouvelle version de inkscape, par exemple, cela me conviendrait. Là il faut l'activer pour un paquet spécifique à installer puis se rappeller de penser à le désactiver pour éviter de tirer tout ce qu'il y a dans backports.

          Le switch --media de urpmi est fait pour ça.
          Tu ajoute les sources backports mais tu les désactive, quand tu as besoin de quelque chose dedans tu les met à jours explicitement avec urpmi.update et tu installe en précisant à urpmi qu'il peut aller chercher dans ces sources.

          Ou récipoquement quand tu fais un --auto-select, tu ajoute un --exclude-media en précisant les médias de backports.
          • [^] # Re: www.backports.org

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

            C'est bien ce que je dis : par défaut, ils sont pris en compte dès qu'ils sont restés activés, ce qui peut générer des comportement non souhaités (en tout cas de mon point de vue).
            Clairement, par le jeu des dépendances c'est quasi l'intégralité (bon ok je grossis le trait) des paquets qui se trouvent backportés... sans compter ceux qui réclament à cor et à cri les toutes dernières versions de KDE (c'était plutôt des trucs comme compiz ou beryl à l'époque qui était aussi réclamé, mais demandait une installation manuelle sous peine de casser sa distrib'...) donc bon, quitte à avoir un système cassé autant être en cooker et l'assumer...
            D'autant, que la plupart du temps, la justification de certains pour avoir la toute dernière version, c'est souvent "pour avoir la dernière version", pas une fonctionnalité ou une correction de bug citée (ce qui serait déjà plus justifié).

            En tout cas, le système de backports est déjà un peu plus maîtrisé que SoS ou MDE... et j'aurai tendance à être confiant pour la suite si le projet Taster permet de mobiliser suffisamment de monde prêt à faire des retours (en français en plus, cela étant souvent un point de blocage avec l'anglais :/).
            • [^] # Re: www.backports.org

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

              Les paquets rétro-portés se justifient tant qu'il ne s'agit pas de devoir mettre à jour la moitié des bibliothèques partagées de la distribution cible. En effet, la plupart des logiciels se contentent souvent des versions distribuées par les saveurs stables.
  • # Entièrement d'accord

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

    Je te rejoint complétement. Cela fait un moment que je suis agacé par 'le' système de packaging des logiciels des distributions GNU/Linux. C'est vrai qu'il amène un grand nombre d'avantage mais aussi rend la vie très difficile lorsque la version du logiciel que l'on cherche n'est pas disponible.

    Pour prendre un exemple que je connais bien, je sors les version Windows et GNU/Linux de GCompris en même temps mais pour beaucoup d'utilisateur GNU/Linux ils devront attendre des mois ou des années avant de pouvoir l'utiliser.
    • [^] # Re: Entièrement d'accord

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

      ET s'ils attendent trop longtemps, ils ne seront plus enfants.
      Donc ils ne voudront plus utiliser GCompris.
      C'est vrai que c'est assez gênant pour ton logiciel.
    • [^] # Re: Entièrement d'accord

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

      oui Bruno, mais le problème essentiel est l'autonomie d'un logiciel : rien n'empêche de fournir Gcompris qui marchera sur n'importe quel Linux, comme les boîtes propriétaires le font (RealPlayer - Flash - etc.). Mais vu les besoins de Gcompris, cela fera 400Mo le paquet... avec sa propre libc, python etc.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Entièrement d'accord

        Posté par . Évalué à 1.

        Rien n'empêche, c'est vite dit...

        Dans le cas de Wormux, j'ai essayé à plusieurs reprises de faire un binaire statique pour contrer ce problème, je m'y suis cassé les dents. (Libcurl est notamment une plaie à ce niveau)
      • [^] # Re: Entièrement d'accord

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

        Les dépendances que tu cites sont dans le LSB donc dans toutes les distro principales. Un bon début est de développer avec une base LSB mais ce n'est qu'un partie du problème.

        Le problème ensuite c'est de pouvoir installer / désintaller simplement et proprement des logiciels en dehors du système de packaging de la distro.
        • [^] # Re: Entièrement d'accord

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

          Le problème ensuite c'est de pouvoir installer / désintaller simplement et proprement des logiciels en dehors du système de packaging de la distro.
          C'est justement là où il y a un problème, toute personne qui gère un peu plus de 2 postes ne veut pas avoir à gérer de logiciels en dehors du système de paquets de sa distribution, c'est la porte ouverte à toutes les fenêtres®...
        • [^] # Re: Entièrement d'accord

          Posté par . Évalué à 3.

          Juste en passant, et comme je ne l'avais jamais fait (mea culpa): merci à toi et à tous les autres dev et contributeurs pour le super soft qu'est Gcompris.
          Mes filles adorent!!
          • [^] # Re: Entièrement d'accord

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

            Cool un utilisateur ;)

            Au nom de toute l'équipe, Merci.
            • [^] # Re: Entièrement d'accord

              Posté par . Évalué à 2.

              Mais de rien, je le pense vraiment.

              Quand tu écris "un utilisateur", j'espère que tu ne penses pas que je suis le seul!! J'en aurais la nausée....
              • [^] # Re: Entièrement d'accord

                Posté par . Évalué à 3.

                Je te rassure tu n'es pas tout seul à l'utiliser.

                Je l'avais installé dans le Master que je deployais dans les ecoles ( 400Pcs)
                Je l'ai installé sur le PC de ma copine (pour sa fille je precise)

                Et franchement j'aime bien le logiciel.
              • [^] # Re: Entièrement d'accord

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

                Non rassure toi, c'était une boutade. Sans base utilisateur après 8 ans de développement je pense que j'aurai déjà abandonné depuis longtemps.

                Comme tous les projets libres je ne sais pas compter le nombre d'utilisateur mais ça doit être au moins très beaucoup ;)
    • [^] # Re: Entièrement d'accord

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

      En même temps rien ne t'empêche d'avoir comme cible de développement un LSB pas trop récent, ce qui devrait permettre de packager sans trop de bidouille pour la majorité des versions encore maintenues de distribs majeurs. Il n'y a pas beaucoup de barrières à passer ensuite pour envoyer un paquet qui marche dans backports, c'est d'ailleurs une démarche que devraient faire les "packagers occasionnels" plutôt que de multiplier les dépôts avec 3 logiciels à chaque fois dedans.
  • # Reflexion à voix haute

    Posté par . Évalué à 4.

    En lisant ton article je me demandais s'il ne serait pas possible de créer un nouveau projet dont le but serait :

    1. de créer un logiciel qui permettrait de fournir les informations nécessaires à l'installation d'un paquetage sur une distribution (répertoires par défaut des libs, configuration, blah blah blah...)
    2. de packager des applications pour être géréres et installées par ce nouveau logiciel.

    En quelques sorte, un gestionnaire d'application indépendant de la distribution, et un dépot de logiciels utilisables par ce gestionnaire d'application.

    En même temps je ne sais pas ce que ça vaut comme idée. C'est certes moins sesky que de créer une nouvelle distribution, mais je pense que ça irait dans le bon sens...
    • [^] # Re: Reflexion à voix haute

      Posté par . Évalué à 9.

      Mon petit doigt me dis que quelque chose qui sert à ça existe déjà : le Build Service openSUSE, qui est déjà largement utilisé (entre autres choses) pour créer des Backports pour openSUSE, mais qui permet aussi de le faire pour d'autres distributions.

      C'est pour l'heure assez peu utilisé en dehors d'openSUSE, et c'est bien dommage à mon avis.

      http://en.opensuse.org/Build_Service
      • [^] # Re: Reflexion à voix haute

        Posté par . Évalué à 2.

        Et donc, une question me brûle les lèvres : est-ce que quelqu'un a déjà envisagé d'utiliser cet outil pour le généraliser ?
        • [^] # Re: Reflexion à voix haute

          Posté par . Évalué à 2.

          Tout dépend de ce que tu définis par "quelqu'un" et "utiliser" :)

          En ce qui concernent la création de paquets, les statistiques actuelles du dépôt central openSUSE donnent :
          There are now 3716 projects, 48754 packages, 7204 repositories and 8606 confirmed users.

          toutes achitectures (i586, x86_64, ia64) et toutes distributions confondues (mais surtout openSUSE).

          Egalement, rien n'empêche n'importe qui (distribution, ou developpeur d'un projet quelconque) d'installer une copie locale sur sa ferme de compil/son ordinateur personnel, puique les sources du Build Service sont disponibles librement (mais on perd l'avantage de l'utilisation directe de la ferme de compilation du projet openSUSE).

          Le but premier du Build Service, outre de creer des paquets pour plusieurs distrib facilement, est de dynamiser les interactions entre les projets (en recompilant automatiquement les paquets lors que c'est nécessaire), tout en ayant un lien direct avec les sources upstream.

          Egalement, le BS peut s'utiliser de façon décentralisée, en "pointant" vers un Build Service central (celui d'openSUSE par défaut), les différents projets restant liés entre eux.

          Les statistiques exactes sont donc difficiles à obtenir, et savoir "qui" l'utilise (et dans quel but?) est chose impossible. Mais aucune distribution majeure ne l'utilise à ma connaissance, chacune ayant son propre système local.
    • [^] # Re: Reflexion à voix haute

      Posté par . Évalué à 5.

      ca existe et ca tourne à merveille, je crois que tu parles d'un projet comme celui-ci :

      http://www.autopackage.org/

      Decouvert suite à la mise à jour du protocole reseau MSN qui empechait les utilisateurs de logiciels tiers de se connecter ( classique ). Les depots des distribs ne pouvaient pas toutes suivre le rythme sur ce coup là et le projet aMSN fournissait un paquet mis à jour avec installeur. Bonheur.
  • # C'est du boulot

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

    Je suis du même avis, ça m'embête de devoir reinstaller tout un système pour juste avoir les derniers logiciels "utilisateurs" (c'est pour ça d'ailleurs que j'utilise le binaire officiel de Firefox plutôt que celui de la distrib).

    Cependant, le problème de cette idée de fournir ces logiciels en backport, c'est que ça demande du temps. Et les mainteneurs de paquets ont déjà assez de boulot comme ça pour mettre à jour les paquets des versions en développement des distribs.

    Et je ne parle pas des backports sur les version n-2, n-3 des distribs, la charge de travail augmentant alors très rapidement (il faut avoir une machine avec ces vieilles distribs, probablement patcher le nouveau logiciel pour qu'il puisse encore fonctionner sur la vieille distrib etc...)

    Bref, à mon avis, si les distribs ne font pas vraiment, c'est plus par manque de ressources qu'autre chose.
    • [^] # Re: C'est du boulot

      Posté par . Évalué à 2.

      effectivement pour les distrib communautaires, ce n'est pas évident. Peut-être que les distributions commerciales auraient quelque chose à proposer à ce niveau là, surtout celles qui s'orientent vers le "bureau".

      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: C'est du boulot

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

        Hum, est-ce que les distros veulent vraiment cela ou préfèrent-elles garder leurs utilisateurs sous contrôle ?
      • [^] # Re: C'est du boulot

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

        La charge de travail sera la même pour une distro commerciale, sauf erreur de ma part.
        Et quand on voit que les distros commerciales ont des équipes de 30 à 50 personnes, et que debian a 1000 developpeurs, plus de 500 chez gentoo et fedora, je suis pas sur qu'une distro commerciale possède plus de moyen qu'une distro communautaire.
        • [^] # Re: C'est du boulot

          Posté par . Évalué à 8.

          je sais pas si ils bossent le même nombre d'heures par semaine, donc faudra se méfier des comparaisons à la hache comme ça
    • [^] # Re: C'est du boulot

      Posté par . Évalué à 2.

      C'est compliqué parce que les processus et outils des distributions traditionnelles manquent sérieusement de souplesse, et puis le modèle actuel ne semble pas trop mauvais dans les autres cas que le desktop personnel (qui ne rapporte pas d'argent parait-il).

      il suffit de faire exactement l'inverse de Debian (Debian est une super distro, ce n'est pas le propos) pour faire une distribution core figé, haut niveau roulant (complètement roulant, pas figé et backport en complément, trop de boulot) maintenable, et on tombe un peu sur Archlinux:
      - le moins de patchs possible, laisser le boulot d'upstream à upstream.
      - packaging facile et on ne cherche pas à tout packager (le premier permettant le second)
      - minimum de bureaucratie, règles souples (soft freeze, on préfère packager une release bugfix only plutôt que faire des backports de patchs => moins de taf, plus de corrections de bugs, et plus de risques aussi, certes, mais si upstream release n'importe comment, voir avec upstream :p)
      - on ne supporte qu'une ou deux archi

      J'aime bien Archlinux comme elle est pour mon desktop, mais j'aimerais beaucoup une arch semi figé pour mes petits serveurs perso (avec les logiciels serveurs en soft freeze) et les quelques desktops perso dont je m'occupe.

      Peut-être que je me fais beaucoup d'illusions sur la complexité et la charge de travail.
      • [^] # Re: C'est du boulot

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

        Peut-être que je me fais beaucoup d'illusions sur la complexité et la charge de travail.
        le fait de s'appuyer sur upstream est le meilleur àmha aussi, mais cela suppose que l'upstream a connaissance du packaging dans chacune des distributions :
        - cela ne signifie pas que les développeurs ont toutes les distributions à leur disposition (c'est rarement le cas et encore moins dans toutes leurs déclinaisons de versions)
        - cela signifie qu'il y au moins un utilisateur avancé tant du logiciel que de la distribution en mesure de maintenir ce qui est nécessaire pour le packaging
        - éventuellement, doublonner les outils permettant de packager dans chaque gestionnaire de version (et là ça représente du boulot, un doublon qui peut être désynchronisé...) : c'est ce que j'avais sur un projet : un répertoire package avec debian / mandriva / fedora / arch...
        - c'est là où il manque un outil distribué en libre qui a vocation, si j'ai bien compris, à aggréger les informations de VCS distincts et permettant ce travail sur "un seul source distribué" dans leur VCS respectifs, donnant visibilité à chacun de l'ensemble dans son dépôt préféré avec lequel il est habitué à travailler. C'est notamment pour cela que c'est rageant que launchpad ne soit pas encore distribué en libre (toujours repoussé aux calendes grecques, sans date ferme...)
  • # Rolling release

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

    Moi j'aime bien le concept de rolling release de Gentoo ou Arch.

    En gros les nouvelles versions sont intégrées au fur et à mesure dans la distrib stable. Il n'y a donc jamais vraiment de "release" de la distrib, juste un snapshot tous les X mois qui permet de l'installer.

    C'est pas mal, mais je crois pas qu'il y ait de distrib "grand public" qui fasse ça (genre Ubuntu ou openSUSE)
    • [^] # Re: Rolling release

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

      Moi aussi, j'aime bien. Et je ne comprend pas vraiment pourquoi il y a si peu de distributions qui l'utilisent ...

      Ce que j'aime bien aussi, c'est qu'il est facile de créer ses propres paquets. Et donc d'installer un logiciel non encore packagé, sans ignorer le gestionnaire de paquets.

      Dans l'optique de migration vers une distribution plus attractive (telle que fedora) je travaille plus ou moins sur un logiciel qui permettra à partir d'un fichier de description (équivalent des ebuild, RPM .spec, PKGBUILDs) qui pourrait permettre de générer un paquet pour chaque distribution.
      Ce fichier décrira où sont les sources (URL), comment les télécharger, décompresser, patcher, compiler et installer puis permettra de faire un paquet binaire natif de la distribution utilisée. Mon but serait de créer un sie web où on puisse s'échanger ces fichiers, et où chacun pourra l'améliorer pour mieux prendre en compte sa distribution.
      • [^] # Re: Rolling release

        Posté par . Évalué à 2.

        jusqu'à présent j'utilisais Debian Sid qui était plutôt satisfaisante, et ne m'avait jamais réellement bloqué. Par certains côté, cela faisait comme une rolling release. Mais depuis quelques temps, en utilisant les paquets de debian-multimedia, cela bloquait vlc. Finalement, on m'a laissé entendre que Debian Sid ce n'était pas fait pour être réellement utilisé, qu'il fallait prendre Debian Stable, et que si je trouvais les paquets de Debian Stable trop vieux, je n'étais pas fait pour Debian. Dont acte.

        J'aime aussi la possibilité de faire ses "formules" avec Archlinux pour créer des paquets, c'est relativement simple et rapide, et surtout permet d'en faire profiter facilement tout le monde. Pour le moment je vais rester sur archlinux qui semble bien me convenir, puisque leur but c'est de faire une distribution moderne, utilisant des logiciels récents, et utilisable.

        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: Rolling release

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

          Sid est parfaitement utilisable, elle n'est simplement pas faite pour être utilisée par quelqu'un qui n'est pas en mesure d'anticiper et gérer des problèmes de dépendances (surtout si on se met à ajouter les dépôts annexes) :)
          Je vis très bien sous Sid depuis plisieurs années avec plusieurs machines différentes, avec apticron, apt-listbugs et en prenant le temps de lire, ça marche très bien !
          Pour ceux qui veulent du pas vieux sans prise de tête, c'est testing...
          • [^] # Re: Rolling release

            Posté par . Évalué à 3.

            sid ou testing, ce fut "ben merde ! où est passé VLC ?!?" pendant de longs mois. et ça peut concerner n'importe quel autre paquet qu'un utilisateur considèrerait pourtant comme vital.

            alors pour le coté "sans prise de tête", tu repasseras
            • [^] # Re: Rolling release

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

              J'ai bien une vague idée de par où il était passés, mais pas sûr que ça te plaise :) cependant, je ne l'ai jamais perdu !
              Bon, c'est peut-être parce que j'ai les 3 "saveurs" debian + stable/security + multimedia dans mon sources.list
              • [^] # Re: Rolling release

                Posté par . Évalué à 2.

                bah voila : ton "multimedia" c'est le fruit du travail de Christian Marillat, c'est à côté, à part, en complément, comme tu veux, mais...

                ...ça ne fait pas partie de Debian.
                • [^] # Re: Rolling release

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

                  Je sais bien qu'il est "en dehors" et comme je le dit ailleurs, ce n'est pas la panacée, cependant, il est suffisamment légitime et bien géré pour que je puisse me permettre de le conserver (un peu comme plf à mon époque Mandrake).
                  J'ai essayé unofficial, et d'autres petits (freeplayer), ils n'ont pas fait long feu...

                  Backports ne faisait pas partie de Debian à l'origine non plus, l'espoir fait vivre :)
                  • [^] # Re: Rolling release

                    Posté par . Évalué à 2.

                    ben disons que si au fil de la semaine j'utilise 6, 10 ou 15 logiciels libres que je qualifierais de "majeurs" et normalement inclus dans Debian, et que pour rester à jour je doive inclure et surveiller, bref rester dépendant de, 6 10 ou 15 dépots tiers, je pense qu'il se posera assez vite un gros problème quand les dépendances de tout ce petit monde vont se marcher sur les pieds

                    on perd juste la cohérence des dépendances que Debian gérait à peu prêt correctement. maintenant, chacun son trip, hein... et, oui, je sais que des fois y'aura pas le choix.
                    • [^] # Re: Rolling release

                      Posté par . Évalué à 4.

                      En fait Marillat c'est un peu une exception, genre par ailleurs il est développeur Debian, il sait ce qu'il fait, et il a par ailleurs l'utilité de permettre de lire sans effort une palanquée de formats de fichiers que ces intégristes de Debian n'incluent pas forcément par défaut.

                      Debian-multimedia c'est un truc qui tourne sans trop de soucis depuis quelques temps, genre ça a changé de nom et d'adresse il doit y avoir un ou deux ans, sinon j'y touche tellement rarement qu'il se fait oublier ...

                      Il m'est arrivé d'ajouter des dépots, mais c'est un peu le seul qui soit utile et pérenne pour ça ...
                      • [^] # Re: Rolling release

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

                        Ce n'est pas parce que Christian Marillat est DD qu'il sait nécessairement ce qu'il fait. Les développeurs Debian restent des êtres humains et sont sujets aux erreurs (genre OpenSSL...).
                        Ce dernier a été largement critiqué pour sa gestion des paquets Debian du projet Gnome (dont il avait le second monopole avec un japonais) avant la constistution d'une équipe dédiée à Gnome comme il y en a pour KDE et d'autres gros projets.
                        Christian a d'ailleurs abandonné tous ses paquets relatifs à Gnome au profit de cette équipe car il n'apprécie manifestement de travailler en équipe. Alors, le jour où il sera malade (tout ressemblance avec l'auteur d'une des plus vieilles distributions Linux serait fortuit) ou autre, tu peux dire adieu à ton cher dépôt tiers.
                        Christian est loin d'être une référence en la matière : les auteurs de MPlayer n'ont guère apprécié son paquet Debian, ce qui a fait traîné son intégration officielle en longueur.
                        En outre, si tu as des problèmes avec un de ses paquets, tu ne pourras plus compter sur la communauté Debian pour les corriger.
        • [^] # Re: Rolling release

          Posté par . Évalué à 2.

          Sid à tendance à "se figer" de temps en temps, genre un peu avant la sortie de la nouvelle stable. Peu de grosses nouveautés ou de gros changements sont effectués pendant cette période, et c'est moins "bleeding edge". Mais globalement c'est très à jour.
  • # Debian

    Posté par . Évalué à 6.

    On peut penser à une Debian mixte Stable/Testing (ou unstable) avec Apt-pinning. On garde notre base en Stable, et on ne prend que les quelques programmes qui vont bien en Sid. Avec la magie des dépendances, on ne prend que ce qui faut.

    On va me dire qu'au bout d'un moment il y a beaucoup de paquets qui seront mis à jour, justement à cause des dépendances. Mais s'ils sont mis à jour, c'est qu'ils sont nécessaires, donc que de toute façon on ne peut pas s'en passer, à moins d'avoir plusieurs versions de GTK et de QT, etc.

    On ne peut pas tout avoir...

    ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

    • [^] # Re: Debian

      Posté par . Évalué à 2.

      Je plussois !
      Je ne connais pas "Apt-pinning" mais dans Debian il est possible sur une stable d'installer des paquets (et ces dépendances uniquement) provenant de testing ou sid. Pour cela il faut correctement renseigner son fichier de conf en définissant les priorités des dépôts et en choisissant quelle version on souhaite installer (avec synaptic par exemple).
      • [^] # Re: Debian

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

        Très belle description de la technique dite "d'apt-pinning" :)
        • [^] # Re: Debian

          Posté par . Évalué à 2.

          Ah, c'est ça le nom... je ne le connaissais pas, comme quoi Debian c'est comme le sexe, on fait des trucs super sans connaître le nom exact de la chose ;)
  • # ça existe déja

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

    et ça s'appelle les bsd. Il suffit de voir qu'il y a une séparation entre le système de base, et les applis autres pour voir que c'est ce que tu veut. Je te conseille donc de jeter un oeil sur netbsd ou freebsd, pour pouvoir faire ce que tu veut. Et si c'est trop root's pour toi, tu as pcbsd, qui vise à simplifier l'installation d'un os basé sur freebsd.

    Sinon, les systèmes de ports ( macports (http://www.macports.org/), portage, parmi tant d'autres ) sont aussi une solution à ton problème.

    Et la dernière solution, c'est simplement de te lancer dans un projet, et de mettre ça au point, car après tout, c'est du libre, personne ne t'empêche de te lancer, et vu le nombre de personne qui demande ça sur linuxfr, tu va facilement trouvé des gens aptes à t'aider, aussi bien en matière de travail, que d'hébergement.

    Alors ensuite, si tu fait ça, tu va devoir faire face à tout les trolls qui vont te faire remarquer que kde, c'est à la fois dans la base et pas dans la base, que Firefox est une plateforme, et que les plugins en dépendent, tout comme openoffice, donc que ça devrait pas forcement bouger, que certains devs veulent avoir la nouvelle version de php/python, que le kernel, pourtant sans conteste de base, offre des tas de features dans les versions plus récentes et qu'il faut donc le mettre à jour, et donc le sortir de la base, et ce genre de choses, mais je ne doute pas que tu va trouver facilement la solution à ce genre de problème
    • [^] # Re: ça existe déja

      Posté par . Évalué à 2.

      tu as raison. Cela ne sera sans doute pas simple. C'est pour cela que les mises à jour ne doivent pas être forcées. Si quelqu'un a besoin de firefox 3, cela sera à lui de vérifier que le plugin indispensable fonctionne bien avec firefox3. Mais cela serait pareil sous windows ou mac os x.
      Pour un environnement de bureau, rien n'interdit à priori de le compiler pour que cela fonctionne avec une libc d'il y a 3-4 ans, sauf bien sûr s'il y a eu trop de modifications entre temps. Pour le noyau linux, une fois le système installé, si on ne branche pas trop de périphériques exotiques dessus, il n'y a pas forcément besoin de le changer.

      Je pense quand même que vous conviendrez qu'il y a un peu des soucis au niveau de l'utilisation de binaires sous linux. Un logiciel de jeu qui sort en 2006 n'est pas certain de continuer à fonctionner en 2008.

      Autre problème, c'est que l'on a souvent des références à des libmachins.so.4 alors que l'on en est à la libmachins.so.6, dans 90 % des cas en faisant un lien symbolique vers la dernière version, cela fonctionne très bien, cela serait bien que cela puisse tester automatiquement qu'une version plus récente existe plutôt que de bloquer.

      En ce qui concerne PCBSD, je pense que je vais le tester prochainement, je viens de voir qu'une beta de la version 7 venait de sortir.

      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: ça existe déja

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

        Si quelqu'un a besoin de firefox 3, cela sera à lui de vérifier que le plugin indispensable fonctionne bien avec firefox3. Mais cela serait pareil sous windows ou mac os x.
        C'est une des plus grosses valeur ajoutée des distibs Linux par rapport aux OS du mal : l'intégration et la cohérence des dépendances logicielles. Si c'est pour se taper de la veille sur 120 sites web, télécharger toutes les semaines les trois mis à jour, les tester, désinstaller l'ancienne version et installer la nouvelle, va voir chez Slack...

        Un logiciel de jeu qui sort en 2006 n'est pas certain de continuer à fonctionner en 2008
        Solaris se targue d'avoir une ABI Stable depuis 1992 (de mémoire), tu devrais essayer, le jeux de 1994 doivent encore fonctionner :) Mais là, on est plutôt dans le problème inverse à celui évoqué à la base, à savoir faire tourner KDE 4.1 et openoffice 3.0B2 sur un noyau 2.2 :)
      • [^] # Re: ça existe déja

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

        Autre problème, c'est que l'on a souvent des références à des libmachins.so.4 alors que l'on en est à la libmachins.so.6, dans 90 % des cas en faisant un lien symbolique vers la dernière version, cela fonctionne très bien

        Pas du tout, efface ! Si le SONAME a changé, ça veut dire que l'api a été cassée. Forcer l'utilisation d'une lib avec une SONAME différente, c'est jouer au loto en espérant que ce qui a été cassé n'est pas utilisé dans le programme…
  • # Gentoo ? Arch ?

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

    C'est le modèle de développement de Gentoo.
    Il y a une évolution continue qui fait que les nouvelles versions arrivent au fil de l'eau. C'est d'ailleurs pour moi LE point fort de Gentoo.

    Il me semble que Arch reprend ce principe mais avec des paquets compilés.
    • [^] # Re: Gentoo ? Arch ?

      Posté par . Évalué à 5.

      Le bleeding-edge sous Gentoo, ça a subit un sacré recul, ces dernières années, hein...

      X.org (tout, sauf la base, en ce qui me concerne) voit encore sa version 7.3 tilde-archée... tout comme Firefox 3...

      ... et m'est avis que c'est tout sauf un mal, vu les problèmes qu'ont pu engendrer les dé-tilde-archage hâtifs dans cette, n'en reste pas moins, fantastique distro. A la limite, le point fort dans ce cas, c'est d'être fait pour proposer plusieurs versions des applis de manière concurrente (même si on n'en installe qu'une seule à la fois)...

      ... un peu comme les backports Debian, ou le apt-pinning (dont il faut parfois accepter les conséquences néfastes) en somme.



      Maintenant, ça me paraît davantage être quelque chose qui intéresse les utilisateurs "avancés" plutôt que le grand public... ma mère utilise une Debian stable, et honnêtement, firefox 1.5, 2.0 ou 3.0, elle s'en fout complètement ; elle n'a même pas conscience qu'il peut y avoir des différences.

      Avoir la dernière version pour pouvoir dire "t'as vu, j'ai la dernière version", je ne vois pas bien où ça mène... ni à quoi ça sert ; oui, firefox 3.0 et Gimp 2.4 sont un peu mieux que les versions précédentes... de là à dire qu'il y a un monde qui les sépare, je n'irais franchement pas jusque là : firefox 3 est toujours lent et très mal intégré sous X.org (seule et unique appli qui ne prend pas en compte mon dpi peu commun, fonctionnement bizarre du presse papier avec le bouton du milieu, intégration exécrable aux thèmes gtk, ...), et il manque toujours les dossiers de calques et les fonctions d'impression pro à Gimp 2.4... dont acte.



      A la limite, ce que je préfèrerais, c'est que tout (et quand je dis "tout", je pense vraiment à "TOUT") ce qui concerne le support du matériel soit mis à jour plus souvent, de manière globale... comme lcdproc dans Debian, qui n'a pas été mis à jour depuis la sortie d'Etch, fut-ce en backport, et qui ne l'est toujours pas dans Lenny (même si la page QA laisse un poil d'espoir en laissant penser que l'exception de non-freeze de ce paquet va permettre de le voir upgradé dans la prochaine Stable)...



      Voire à ne pas confondre non plus "stable", "fiable", "fonctionnel" et "récent"... les régressions, c'est monnaie courrante ; prenons X.org pour exemple... X.org 7.3 (en attendant que le 7.4 sorte enfin... si jamais...) est peut-être plus récent et plus fiable que les précédents quant à la gestion du multi-écran, mais il est indubitablement moins fonctionnel sur ce point ; avec le 7.1, on pouvait faire du multi-GPU, même si c'était au prix du manque d'accélération 3D... Avec cette version qui est encore celle de l'actuelle Debian stable (ie stabilisée, ie figée à une version qui n'est pas forcément la dernière en date : ni plus, ni moins), je n'ai aucun problème à avoir 3 écrans avec une accélération 2D libre...

      Alors, laquelle est la mieux ? Et bien ça dépend, justement...



      Ce qui est bien, au fond, c'est d'avoir le choix. Debian stable ne satisfait plus l'auteur du journal ? Pourquoi ne pas utiliser une Lenny, par exemple, en ce cas ? A défaut d'être "stable" (ie, ses paquets ne sont pas figés, ni plus, ni moins), elle se révèle globalement très fiable depuis la sortie même de Etch (le seul gros problème dont je me souvienne, hors problèmes de sécu, plus longs à corriger que dans les autres Debian, c'est un paquet de grub qui a été merdeux pendant quelques heures)...

      Même si je ne serais pas du tout contre un poil de granularité en plus, avec des backports plus fournis, la diversité des distros fait que, de la granularité, justement, il y en a déjà pas mal.
      • [^] # Re: Gentoo ? Arch ?

        Posté par . Évalué à 4.

        pour firefox 1.5 ou 3.0, je pensais aussi pareil, pour un utilisateur non averti c'est plus ou moins la même chose, mais le problème c'est quand ils viennent te dire que certains sites ne s'affichent pas bien, qu'ils ne comprennent pas pourquoi, ben moi j'ai vite compris que cela venait de la version du navigateur.

        Et c'est là que l'on aurait aimé pouvoir installer facilement la dernière version, mais elle n'était pas dans les dépôts (et honnêtement, avec cette version 10.1 d'opensuse, pendant que le gestionnaire de paquet s'initialisait, on avait le temps de télécharger et d'installer 3 fois un .exe sous windows... heureusement cela s'est amélioré avec la version 11)
        J'ai pu la télécharger depuis le site de mozilla (et encore parce que j'avais du x86 et pas du 64 bits qui n'est pas fourni, et je pense que la version 3 n'aurait pas fonctionné.

        Pour les régressions de X, je pense que X fait partie des paquets de base à ne pas modifier une fois une machine installée. Car je parlais bien de stabiliser si possible une version de base dans le but de garder un système opérationnel sur le long terme, pas dans le cas de réinstallation ou de nouvelles installations.

        Pour parler plus concrètement, j'ai installé dans la PME où je travaille plusieurs ordinateurs sous windows il y a 5 ans. Besoins : openoffice, firefox, émulateur de terminal (putty ou équivalent). Depuis 5 ans je n'ai pas touché à ces machines ni à leur système, à part faire évoluer openoffice et firefox.

        Sur des postes similaire avec linux cette fois, j'ai comparativement passé plus de temps pour pouvoir mettre à jour ces logiciels, et j'ai d'ailleurs dû faire le plus souvent des mises à jour complètes du système pour cela.

        Lorsqu'il s'agit d'un ordinateur perso, que l'on fait évolution selon ses besoins et ses capacités, c'est un peu plus facile à gérer que de placer un utilisateur devant un linux et lui proposer de mettre à jour son firefox ou openoffice via pkgsrc ou en le compilant à la main...

        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: Gentoo ? Arch ?

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

          pour firefox 1.5 ou 3.0, je pensais aussi pareil, pour un utilisateur non averti c'est plus ou moins la même chose, mais le problème c'est quand ils viennent te dire que certains sites ne s'affichent pas bien, qu'ils ne comprennent pas pourquoi, ben moi j'ai vite compris que cela venait de la version du navigateur.
          Et Firefox 2.0, il ne compte pas ?
          Je veux bien que Firefox 1.5 soit « obsolète » mais de là à prétendre que Firefox 3.0 soit complètement indispensable, c'est comme prétendre qu'il faudrait utiliser IE7 et non IE6.
          Pourtant de nombreux utilisateurs (environ 30%) utilisent encore IE6... Preuve que la course aux versions ne concernent pas tout le monde non plus. Et parmi ceux qui ont fait la mise à jour, c'était parce qu'elle était présentée comme une mise à jour *de sécurité* !...
          La plupart des distributions fournissent à la fois Firefox 2.0 et Firefox 3.0 et, pour citer deux exemples, le site des impôts et de ma banque ne supportent que le premier. Et bien que le second fonctionne, ce n'est pas toujours sans mal : pour les impôts, il a même fallu bidouiller.
          Ce sont sans doute des cas particuliers mais il s'agit de sites à l'audience non négligeable.
          D'ailleurs, quand certains sites ne fonctionnent pas, c'est qu'ils sont d'abord conçus pour IE et non pour Firefox : changer de version ne résoudra pas le problème de fond.
          • [^] # Re: Gentoo ? Arch ?

            Posté par . Évalué à 1.

            c'est comme prétendre qu'il faudrait utiliser IE7 et non IE6.

            Ah mais il ne faut plus, ça fait des années qu'il faut jeter cette saleté, par pitié arrêtez d'utiliser cette merde d'internet explorer 6 (et puis le 7 n'est pas encore formidable non plus).
            Ça nous simplifierait tellement la vie au boulot si on pouvait se permettre de laisser tomber la compatibilité avec ie6.
            • [^] # Re: Gentoo ? Arch ?

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

              Je ne prétends pas qu'il ne faudrait pas le jeter aux orties mais je fais un simple constat de la réalité. N'importe quelles statistiques d'un site à l'audience large pourront en faire de même. Il y en une certaine inertie dans ce genre de migration, hélas...
              • [^] # Re: Gentoo ? Arch ?

                Posté par . Évalué à 3.

                Je le sais, bien sur, mais ça fait du bien de temps en temps de pouvoir le déplorer.
                Et je ne me gêne pas devant les clients de faire remarquer que ce truc pose des problèmes.
    • [^] # Re: Gentoo ? Arch ?

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

      Si c'est le même « bonheur » sous Gentoo que sous Arch, bonjour les mises à jour...

      Depuis hier soir, je suis un utilisateur comblé et heureux d’ArchLinux 64 bits. Même s’il m’a fallu près de 4 heures entre le début de l’installation et le lancement d’un firefox 3.0 pré-béta3 compilé maison. [...]
      http://frederic.bezies.free.fr/blog/?p=652
      • [^] # Re: Gentoo ? Arch ?

        Posté par . Évalué à 1.

        lancement d’un firefox 3.0 pré-béta3 compilé maison

        oui mais c'était en décembre 2007. Maintenant firefox 3 existe dans les dépôts bien entendu :

        http://archlinux.org/packages/extra/x86_64/firefox/

        Au niveau des mises à jour, je n'ai jamais eu de problème avec, pourtant utilisant encore Debian en double boot, je ne lançais alors archlinux qu'épisodiquement, donc les différentes mises à jour étaient assez conséquentes, mais cela n'a jamais rien cassé.

        Pour l'installation, entre mon premier boot sous arch et le lancement de firefox cela a dû mettre moins de 3 minutes, mais il faut dire que j'avais triché, ayant installé archlinux depuis un chroot sous Debian :)

        Après, c'est sûr que cela reste assez brut de fonderie, mais justement l'intérêt c'est de pouvoir maîtriser la plupart des processus que l'on met sur le système. Après avoir lu le guide détaillé on sait un peu plus ce qui se passe.

        Pour ce que tu disais de firefox 2, c'était possible de l'installer sur l'opensuse 10.1, mais c'était parce que l'architecture était en 32 bits, mozilla ne fournissant pas de paquet 64 bits. Et cela ne change rien au fond du problème : si on veut garder un système sans réinstaller la base, sous linux au bout de quelques mois il n'est pas aisé de faire évoluer la base logicielle. Windows XP sur un ordinateur acheté en 2003 : pas de problème pour installer firefox 3. Asus EeePC acheté en 2008 : ce n'est pas possible sans tout réinstaller.

        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: Gentoo ? Arch ?

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

          Pour ce que tu disais de firefox 2, c'était possible de l'installer sur l'opensuse 10.1, mais c'était parce que l'architecture était en 32 bits, mozilla ne fournissant pas de paquet 64 bits. Et cela ne change rien au fond du problème : si on veut garder un système sans réinstaller la base, sous linux au bout de quelques mois il n'est pas aisé de faire évoluer la base logicielle. Windows XP sur un ordinateur acheté en 2003 : pas de problème pour installer firefox 3. Asus EeePC acheté en 2008 : ce n'est pas possible sans tout réinstaller
          Y compris sous Windows 64 bits ?
          Ensuite, mettre à jour une distribution moderne ne signifie pas ré-installer. Ou alors, il faut carrément changer de distribution.

          On ne peut pas comparer les modes de distribution entre Microsoft© Windows® et Linux car il y a une différence fondamentale : le système n'est pas libre. Les logiciels libres disponibles sous Microsoft© Windows® doivent donc se débrouiller SEUL. Rien n'est prévu pour les acceuillir ni pour gérer les dépendances. Les seules applications gérées par Microsoft sont celles qu'il édite lui-même. On peut mettre à jour Microsoft© Internet Explorer® via Microsoft© Windows Update®. On ne peut pas le faire (du moins pas pour l'instant mais il me semblait que Microsoft© planchait sur une méthode pour distribuer ses applications en ligne) pour Microsoft© Office® parce qu'il s'agit d'une suite logicielle payante. Et il en va de même pour tous les autres logiciels payants qu'ils éditent.
          Quant aux logiciels d'éditeurs tiers, ils doivent se démerder tout seul, si bien que leurs applications sont généralement accompagnées de leur valises de DLL pour pouvoir fonctionner. D'où une gestion des mises à jour de sécurité complètement bordélique : un bibliothèque commune à deux ou trois applications nécessitera autant de mises à jour que d'applications, à condition que les éditeurs en fournissent...

          Si certains développeurs ne veulent pas produire autant de paquets binaires que de distributions majeures (on ne leur demande pas non plus d'en faire pour les 200 et quelques distributions existantes) dont il n'existe finalement que deux ou trois grandes familles (les RPM, les debian et les sources), qu'ils ne viennent pas se plaindre si ces dernières n'incluent pas leurs dernières versions.
          Après tout, les éditeurs de jeux ne jonglent pas seulement avec Microsoft© Windows® mais également avec MacOS© X et les diverses consoles de jeux du marché et ils ne se plaignent pas franchement du nombre de plate-formes... On va sans doute me dire que, certes, ils ont les moyens humains et financiers pour ce faire. Que dire alors des quelques responsables, qui se comptent sur les doigts de la main, de RPMforge qui maintiennent des milliers de logiciels sous forme de paquets RPM pour Fedore, RHEL, CentOS, dont plusieurs versions concurrentes et pour au moins deux architectures différentes ? Qu'ils ont les moyens humains et financiers de le faire ? Non : comme Debian, ils ont des outils pour se faciliter la tâche et cela prouve encore une fois que la prétendue disparité entre les distributions est, somme toute, assez limitée.

          Exemple avec Nagios :
          http://dag.wieers.com/rpm/packages/nagios/

          Donc, s'il se trouve assez de développeurs et d'utilisateurs pour proposer une nouvelle voie à suivre pour les distributions Linux, tant mieux, mais qu'attendent-ils pour se mettre à l'ouvrage ? Gentoo a été un bel exemple de nouvelle voie, Gobolinux aussi : pourquoi pas une autre ?
  • # Pas de problème pour Ubuntu.

    Posté par . Évalué à 1.

    Avec Ubuntu, je ne me suis jamais posé ce problème : une release tous les 6 mois permet d'avoir des softs assez récents.
    Et pour les autres softs qui ne sont pas pris en charge à la sortie, il existe des dépôts spécifique (Banshee, Avant Window Navigator, Miro, ...)

    Bref, moi je ne trouve rien à redire système de paquets Linux, c'est vraiment la chose qui me fait adorer Linux.
    • [^] # Re: Pas de problème pour Ubuntu.

      Posté par . Évalué à 6.

      Avec ubuntu, je conseille tout de même d'attendre un ou deux mois après la sortie de la dernière version pour mettre à jour.
      Ce n'est pas du troll, même si je n'ai pas installe la 8.04, mais les précédentes avaient souvent des petits problèmes, qui sont vite réglés une fois la distrib sortie officiellement.

      Donc je dirais par exemple que c'est le bon moment pour passer a 8.04, et que décembre sera sans doute le bon pour passer à 8.10.
    • [^] # Re: Pas de problème pour Ubuntu.

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

      Je partage ton avis sur le modèle d'Ubuntu, modèle que j'ai adopté alors que j'utilisais quotidiennement Debian Sid.
      Toutefois, je pense également que la multiplication des dépôts est néfaste et qu'il convient plutôt d'attendre que la prochaine version d'Ubuntu soit publiée avant de se jeter sur les dernières versions de quelques logiciels.

      Un autre point que personne n'a abordé, c'est le problème du piratage : il devient très facile, en proposant un paquet de la dernière version du logiciel à la mode (choississez celui que vous voulez) d'introduire des chevaux de Troie dans un maximum de systèmes. Exemple :
      http://www.marsaud.org/index.php/post/2008/07/03/Compiz-Fusi(...)

      PS: et pas de Ubuntu-bashing facile merci car c'est possible avec n'importe quelle distribution si les utilisateurs sont prêts à installer n'importe quoi pour avoir la toute dernière version de leur logiciel favori.
  • # Click'n Run

    Posté par . Évalué à 3.

    J'ai lu récemment un article parlant entre autre des Click'nRun
    http://www.blogeee.net/2008/08/26/les-prochains-eeepc-sous-l(...)

    Est ce que quelqu'un à essayé ?

    J'avoue être assez perplexe, d'autant que le système de gestion de paquet constitue une avancée sur le bordel des setup.exe de windows/dos
    • [^] # Re: Click'n Run

      Posté par . Évalué à 3.

      non je n'ai pas essayé. Quand j'ai découvert les BSD, en voyant le système de PCBSD j'ai trouvé cela assez "débile" de faire des binaires spécifiques à installer comme un vulgaire .exe.

      Mais maintenant avec le recul je vais être très curieux de tester le dernier PCBSD. Normalement le système de gestion de paquets sous-jacent est conservé, mais une surcouche permet d'installer les logiciels que l'on veut. Cela ne sera sans doute pas mon mode d'installation préféré, mais j'aimerais voir ce que cela donne, et le retour des utilisateurs.

      Le système de paquets intégré à la distrib est très bien et très pratique, mais souffre de 3 choses, surtout vis à vis des débutants :

      - obsolescence des programmes (parfois), impossibilité de l'installer comme un simple utilisateur (comparer avec klikk ou autopackage qui permet de laisser l'empaquetage au dev. du logiciel et l'installation par un utilisateur non root)

      - les listes de logiciels dans "synaptic" c'est bien, mais avoir blender coincé entre "barcode" qui gère les normes usuelles d'étiquetage de produits : UPC-A, UPC-E, EAN-13, EAN-8, ISBN et brdesktop-artwork-gnome qui "contains themes and artwork for the GNOME flavour of BrDesktop.", cela ne m'aide pas beaucoup pour savoir si blender est vraiment le logiciel qu'il me faut dans le domaine du graphisme : pas de copie d'écran, pas de commentaire un peu enthousiaste, pas de retour utilisateur etc. Je caricature un peu, mais cela reste un peu un outil d'utilisateur avancé. C'est très bien, mais un lien depuis un site internet vers un dépot click n run ou klikk, cela peut être plus attractif et communautaire (tout en me rendant compte que cela peut poser des problèmes de sécurité et pointer vers http://vilain-pirate.com/rootkit.cnr ). Mais dans le cadre du site d'asus pour le EeePC, cela peut avoir du sens, par ex: http://eeedownload.asus.com/products/overview/gimp avec des notations utilisateur, copie d'écran etc.

      - on pourra rétorquer que l'on peut installer les paquets en téléchargeant l'archive depuis le site debian ou ubuntu, et en l'installant avec gdebi par exemple, mais les paquets sont souvent morcelés en monsuperjeu.deb , monsuperjeu-data.deb, monsuperjeu-audio-low.deb, monsuperjeu-audio-high.deb, monsuperjeu-editor.deb etc. Un paquet avec tout dedans pourrait suffire.

      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

  • # Préoccupation SuSE ?

    Posté par . Évalué à 2.

    En toute honnêteté, j'ai un peu le sentiment que ce problème est accentué par l'utilisation de SuSE (RedHat je ne connais pas/plus assez pour juger).

    Dans une optique Debian et/ou Ubuntu (avec des cycles de vie de version différents), le principe stable/testing/unstable voire experimental permet de conserver un système de base très peu modifié tout en profitant de versions logicielles récentes. Dans les rares autres cas, le nombre de backports demeure appréciable et suffisant. Au pire, une compilation règle les derniers soucis.
    Il est excessivement rare de devoir aller jusqu'à mettre à jour la libc ou autre composant de "bas niveau" entrainant incompatibilités et installations multiples, hors sortie de versions majeures (pas fréquent du côté de Debian ^^) ou mises à jour de sécurité... ou bidouillages incessants aussi (genre desktop) :)

    Quant bien même une installation du système de base deviendrait nécessaire (mise à jour majeure ou besoin de version logicielle), la configuration reste peu touchée et reste cantonnée à de la migration de formats ou à un complément de configuration le plus souvent (si la nouvelle version ne le fait pas pour vous). Cette étape est de plus soit guidée par le système de packaging (dpkg, apt et frontend dans le cas Debian) soit suffisament documentée pour rester simple.
    Et on ne fait pas cela tous les 4 matins non plus.

    A l'inverse, le "Système Manager" type SuSE (YaST) reste une boite noire qui opère pas mal de modifications hors contrôle de l'utilisateur (scripts de mises à jour de la configuration lancés lors de la valiation des changements).
    Cela nécessite beaucoup moins d'intervention dans la majorité des cas simples. Mais à contrario, seuls les cas simples sont gérés au travers de YaST ce qui signifie mettre réellement les mains dans le cambouis lorsqu'on souhaite particulariser son installation (et pas toujours simple de retrouver ses petits) et réinitialisation de sa configuration personnalisée en cas de reinstallations majeures.
    Bref, les distributions type SuSE offre une facilité de façade (sans être péjoratif) mais ne sont sans doute pas adaptées à une utilisation un tant soit peu avancée à partir du moment où on ne souhaite pas suivre leur rythme de release (vrai pour Ubuntu aussi dans une moindre mesure).

    Bon après, on ne peut pas non plus prétendre systématiquement faire le grand écart entre système de base et versions logicielles de niveau utilisateur car chaque application souhaite bénéficier des dernières fonctionnalités offertes par ce même système de base.
    Et d'autres OS ne font pas mieux (voire XP et directX 10 par exemple) du reste.
  • # Ubuntu et les dépôts PPA

    Posté par . Évalué à 1.

    Cette idée de développer plus l'utilisation des backport, ça existe déjà avec ubuntu et les dépôts PPA (personal packager archive) utilisant les outils Launchpad.

    http://planet.ubuntu-fr.org/tag/ppa

    https://help.launchpad.net/PPA
    • [^] # Re: Ubuntu et les dépôts PPA

      Posté par . Évalué à 2.

      Heuuu... non. Il parle de paquets officiels, de qualité et facilement maintenables. Les PPA sont plutôt au niveau de l'AUR d'Arch Linux ou des paquets linuxpackages sous Slackware : qualité aléatoire, maintenance pas toujours au rendez-vous, et bordéliques à gérer dès qu'il y en a plus de quelques-uns. Bien que pratiques ponctuellement, je ne les comparerais pas à des vrais backports.
      • [^] # Re: Ubuntu et les dépôts PPA

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

        En quoi sont ils difficiles à gérer ?

        J'utilise énormément AUR sous ArchLinux (bon il faut dire qu'une grande partie des paquets que j'utilise, c'est moi qui les fait ... mais pas seulement) et je n'ai jamais vraiment remarqué de problèmes.

        Je pense que ce genre de projets devraient être encouragés.

        Après, il y a des problèmes de sécurités éventuels à permettre à n'importe qui de publier un paquet pouvant contenir un virus ou autre ... ce n'est pas impossible. Mais pas plus qu'un autopackage téléchargé sur un site web ou eds .deb qu'on télécharge de la même manière.
        Je dirais que c'est sans doute plus sécurisé (du moins avec AUR) car on a avec chaque paquet les commentaires des utilisateurs, et certains paquets sont créés par des Trusted User (on peut raisonnablement leur faire un peu confiance). Si un problème est trouvé, il sera vite éliminé.

        Pour ma part, j'aimerais bien voir une telle initiative naître qui fonctionnerait avec plusieurs distributions. Comme ça on pourrait bénéficier des paquets d'autres distributions. Il y a bien sûr des différences, qu'il conviendra de gérer, mais la plupart du code reste le même.
        • [^] # Re: Ubuntu et les dépôts PPA

          Posté par . Évalué à 1.

          Oui bien sûr ça pause tout un tas de problèmes (qui sont d'ailleurs soulignés dans le premier lien que j'ai donné)...En gros il faut faire confiance au mainteneur.
          Cela dit certains mainteneurs qui se donnent plus de mal que d'autres, vont se faire un nom avec le temps et vont peut-être voir leur paquets acceptés dans les backports, venant ainsi en renfort des mainteneurs actuels.
  • # ciol, sors de ce corps !

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

    Je ne sais pas si tu as remarqué mais on a déjà quelqu'un[1] qui nous relance régulièrement avec cette idée de construire une « meilleure » distribution avec cette séparation entre la base et les applications. Le problème reste de définir clairement la limite entre cette base et les applications « indépendantes ».

    https://linuxfr.org//~ptitlouis/25313.html
    https://linuxfr.org//forums/10/22694.html

    Si son argumentation est sujet à troll, l'approche peut être pertinente dans la mesure où un certain nombre de personnes, de la communauté française du moins, semblent désirer un tel concept. Sauf qu'on attends toujours le « proof of concept ».
    Je pense qu'aucune distribution généraliste ne pourra postuler pour une telle approche et qu'il faudra en construire plusieurs, spécialisées dans un domaine :

    - Les postes de travail peuvent avoir besoin de nouvelles versions d'OpenOffice.org ou de Firefox ;
    - Les serveurs LAMP de nouvelles versions de PHP, Perl, Apache, etc.

    Par ailleurs, j'estime que les saveurs d'Ubuntu comblent ces besoins (une Desktop, une Server) et que les cycles de 6 mois permettent précisément de bénéficier régulièrement des mises à jour des logiciels les plus plébiscités (Firefox, Thunderbird, PHP, etc.). En effet, il s'agit souvent de gros projets qui ne publient qu'une à deux grosses versions stables (celles qui apportent précisément de nouvelles fonctionnalités) dans l'année... Ce n'est pas pour rien si Ubuntu s'est calée sur le calendrier du projet Gnome.
    En fait, j'ai surtout l'impression que ces reproches portent sur le mode de fonctionnement Debian stable. Pourquoi demander à celle-ci de tout changer quand il existe déjà une alternative viable ?

    [1]: il a également pas mal sollicité fcold sur Usenet mais je n'ai pas retrouvé d'archives pertinentes à ce sujet.
  • # La faute à la "GPL-Bis"?

    Posté par . Évalué à -1.

    La base du pb est sans doute que les API changent trop souvent: Ca touche l'applicatif, mais également les drivers qui sont des nids a emmerdes d'une version sur l'autre.

    Et a lire certaines proses de gourous de la LKML (Genre Greg KH), on peut penser que c'est pas demain la veille que l'API linux soit figée sur, par exemple, une version majeure de kernel (qui dure environ 4 ans... et on ne réinvente pas le HW des machines en 4 ans pour que des interfaces bien spécifiées a la base doivent nécéssairement évoluer).

    En effet, ces API à géométrie variable semblent aussi destiné a motiver les pourvoyeurs de drivers proprio à mettre tout ça en GPL et dans le kernel. Et tout le reste en patit, ainsi que les utilisateurs ce qui n'est jamais très propice à la diffusion. J'appelle ça la "GPL-Bis".

    A titre perso, j'aime assez le concept des LTS ubuntu: Elles durent 3 ans. Une nouvelle version au bout de 2 ans et un an pour changer.

    Ca ne règle pas réellement le pb de décorreler l'applicatif du système, mais disons que c'est un ratio emmerdes de réinstallation/nécéssité de nouveauté qui peut être convenable pour s'accomoder du monde linux tel qu'il est et je doute que ça bouge vite. Surtout que, au benefice du système de paquetage, la maintenance du système est ensuite beaucoup plus simple que sous windows, ce qui donne une organisation différente (plus de migrations complètes, moins de petite maintenance constante à la mimine) mais qui ne prends globalement pas plus de temps pour qui veut passer plus de temps a utiliser son PC qu'a la bricoler.

    Mais c'est dans ce seul cadre que Linux risque hélas d'être vivable pour le grand public!

    Il est vrai qu'en comparaison, un XP supporté complètement entre 2001 et 2010, avec MAJ de sécurité jusqu'en 2014... ça devrait donner à réfléchir à un juste milieu pour linux: L'applicatif compatible sur une version kernel majeure.
    • [^] # Re: La faute à la "GPL-Bis"?

      Posté par . Évalué à 4.

      > La base du pb est sans doute que les API changent trop souvent
      Lesquelles ?
      Gnome/KDE ? stables sur les versions majeures
      glibc ? standardisé (POSIX/SUS), au niveau stabilité on peut pas rêver mieux
      les appels systèmes ? ils ont pas bougé depuis au moins Linux 2.0
      Haaa, tu veux parler de "l'API" interne au noyau ? Franchement, un soft qui tape direct dans l'API du kernel, j'en veux pas :)
      • [^] # Re: La faute à la "GPL-Bis"?

        Posté par . Évalué à -2.

        "Haaa, tu veux parler de "l'API" interne au noyau ? Franchement, un soft qui tape direct dans l'API du kernel, j'en veux pas :) "

        Et tu veux un OS sans drivers aussi? Pourtant, le propos paraissait clair.

        Heureusement que côté applicatif ça se tient... mais sans ce qui est en dessous, on n'en fait pas grand chose.

        Et des mecs comme GKH qui rebelottent la gestion d'exception, de l'usb/pci etc... alors que ça existe depuis des années et qu'aucun chgt hardware profond ne le justifie... et qui clament qu'ils n'en ont rien à pêter que ça emmerde nvidia et autres... devraient aller demander à M$ leur avis sur les effets des ruptures de compatibilité. Et eux ça a été une fois en 25 ans... Linux c'est pluriannuel.

        Pas dit que l'aspect gratos suffise a ce que les utilisateurs pardonnent des années...

        Pourtant, avec la gabégie Vista, y'avait de quoi perçer... Bin non, malgré l'effet netbook ou M$ s'est réveillé, Linux stagne à moins de 2% d'usagers du net.

        Pas dit qu'après le reveil de Redmond, linux ne soit à moins de 1%. C'est con, hein, l'effet GKH and co!?

Suivre le flux des commentaires

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