Journal Gentoo s'essouffle ???

Posté par  (site web personnel) .
Étiquettes : aucune
0
13
mai
2005
Salut,
Juste un petit journal pour parler d'une impression qui est la mienne et qui est peut être fausse.

Mais j'ai l'impression que les qualités que je trouvais à la gentoo et qui m'ont fait migré il y a 3 ans dessus ne sont plus aussi attrayante qu'auparavant. Je m'explique :

- La gentoo était extrêmement réactive en ce qui concerne l'ajout de nouveau packages et surtout la mise à jour de ces derniers. Ce qui me plaisait car j'étais toujours à jour, d'autant plus que j'ai toujours choisi d'être en ~arch. Aujourd'hui je trouve l'intégration des packages beaucoup plus longue et la mise à jours pas très rapide : gnome 2.10 kde-3.4 mise officielle dans portage de evince pour n'en citer que quelques uns.
Bien sûr certain mainteneurs sont très réactifs pour certains de leur packages (le mainteneur de ZSH est génial pour ça).

- Ayant toujours utiliser des x86 j'étais, malgré le point précédent, très content de ma distrib, et c'est tout naturellement que j'ai choisi gentoo pour mon amd64, et la c'est la cata, bon support certe, mais très peu de paquets réellement maintenu, les mainteneurs attendent souvent que les utilisateurs leurs disent que c'est ok avant de mettre une nouvelle version en ~arch alors que la version précédente fonctionnait nikel.

- De plus, il y a de plus en plus d'ebuild disponibles, c'est qui est un bon point, mais j'ai aussi l'impression qu'ils sont de moins bonne qualité qu'avant, la ~arch a de plus en plus de problèmes de compilation (surtout constaté sur ~amd64), mais ce dernier point est discutable en fonction des paquets utilisés, et côté "unstable" de ~arch, les risques de la ~arch sont clairement énoncés par gentoo .

Bref tout ça pour dire, quand je compare à FreeBSD : les paquets sont mieux foutus, moins de problèmes de compilation, beaucoup plus à jour, me permet de tester gcc4.0 sans flinguer le système de base (conserver le compilateur par défaut) et sans avoir à jouer avec un gcc-config pour remplacer mon compilo par défaut le temps de mes tests. le nombre de paquets est aussi plus important et facilement/rapidement intégré dans l'arborescence officielle : cf evince.

Bref je ne vais garder ma gentoo que sur mon portable du boulot, car je n'arrive pas à faire fonctionner word, sous FreeBSD, et même si OOo fait très bien l'affaire pour moi, certains problèmes de compatibilité m'oblige à conserver Word.

Pour conclure, dommage gentoo me plaisait vraiment beaucoup, c'est peut être aussi moi qui suis devenu plus exigeant à force de l'utiliser :)

  • # Re : Gentoo s'essouffle

    Posté par  . Évalué à 6.

    Il ne faut pas perdre de vu que la majorité des mainteneurs sont des bénévoles et n’ont pas forcément toutes les architectures sous la main pour tester.
    Sur le site de Gentoo il est recommandé de soumettre un rapport de bogue lorsqu’un paquet fonctionne bien sur une nouvelle architecture.

    • [^] # Re: Re : Gentoo s'essouffle

      Posté par  (site web personnel) . Évalué à 4.

      Sur le site de Gentoo il est recommandé de soumettre un rapport de bogue lorsqu’un paquet fonctionne bien sur une nouvelle architecture.

      C'est ce que je fait, mais c'est le cas pour beaucoup de distrib.

  • # Faut le dire aussi ailleurs

    Posté par  . Évalué à 4.

    Baptux si tu es le meme baptux que sur le forum gentoo, je posterai aussi mon avis dessus. Il y a beaucoup de discussions (~troll) sur gentoo et son avenir actuellement et je suis sur que ton avis interesserait plus d'une personne

    http://forums.gentoo.org/viewforum-f-35.html(...)

  • # tout le systeme en ~arch ???

    Posté par  (site web personnel) . Évalué à 4.

    Si tu mets ACCEPT_KEYWORDS="~arch", tu cherches les ennuis, non ?

    J'ai plusieurs machines sous gentoo (x86, amd64) et je ne cherche pas du tout à avoir la derniere version de chaque soft ou lib avec la derniere fonctionnalité de la mort qui tue si j'en n'ai nullement besoin.

    En général, j'ai juste gnome et ses dépendances en ~arch (dans /etc/portage/package.keywords) et ca me suffit largement.

    Personnellement 'à jour' signifie que les failles de sécurités connues soit comblées.

    • [^] # Re: tout le systeme en ~arch ???

      Posté par  (site web personnel) . Évalué à 2.

      Je le sais, et c'est aussi ce que je disais dans mon journal, mais je fais simplement un constat de dégradation (constat subjectif et peut être pas justifié d'ailleurs).

    • [^] # Re: tout le systeme en ~arch ???

      Posté par  . Évalué à 2.

      C'est vrai, mais je me souviens que l'une des forces de Gentoo au début, c'était d'avoir un système très à jour. Sur DLFP, on finissait souvent les annonces de nouvelles versions par "déjà dans Portage".

      Moi qui cherche une nouvelle distribution pour un usage bureautique suis refroidi par ce journal, car l'avantage d'un ensemble très à jour, c'est sa convivialité graphique a priori meilleure.

  • # càd ?

    Posté par  (site web personnel) . Évalué à 3.

    - De plus, il y a de plus en plus d'ebuild disponibles, c'est qui est un bon point, mais j'ai aussi l'impression qu'ils sont de moins bonne qualité qu'avant, la ~arch a de plus en plus de problèmes de compilation (surtout constaté sur ~amd64), mais ce dernier point est discutable en fonction des paquets utilisés, et côté "unstable" de ~arch, les risques de la ~arch sont clairement énoncés par gentoo .
    Tu est censé utiliser les critères sur les versions pour choisir toi même laquelle des versions instable marche chez toi (logique - faute de l'existence d'une version qui selon les developeurs Gentoo marcherais mieux).

    Bon, et puis sinon, je vais essayer de te convaincre de la nécessité d'étayer ton argumentation.

    Bref tout ça pour dire, quand je compare à FreeBSD : les paquets sont mieux foutus
    C'est à dire ? Qu'est ce qui te gêne au quotidien ?

    moins de problèmes de compilation
    Curieux, je n'en ai connu qu'un ou deux, en dehors de problèmes matériels.

    beaucoup plus à jour
    Quel package te manque ?

    me permet de tester gcc4.0 sans flinguer le système de base (conserver le compilateur par défaut) et sans avoir à jouer avec un gcc-config pour remplacer mon compilo par défaut le temps de mes tests.
    Quelle solution utilisée par BSD lui permet d'anticiper ton choix d'un compilateur ? En quoi est-elle supérieur à "gcc-config -O" qui permet de repasser à la précedente version de GCC tout en ayant deux installée.

    le nombre de paquets est aussi plus important et facilement/rapidement intégré dans l'arborescence officielle : cf evince.
    Sauf erreur de ma part, l'exemple est mauvais car les discussions sur ce package semblent porter sur des problèmes de useflags, qui (à ma connaissance) ne sont pas disponible sur FreeBSD (quelqu'un pour confirmer ?).

    • [^] # Re: càd ?

      Posté par  (site web personnel) . Évalué à 2.

      Non tu ne choisi pas directement ta version, sauf si tu es en stable et que tu veux certains package ~arch, en l'occurence, je suis en ~ arch donc en instable (je connais les risques), ce que je constate, c'est que avant, les ebuild en ~arch posaient moins de problèmes que ces derniers temps.

      Je compare, les problèmes de compilation et de stabilité des paquets obetenu sur un FreeBSD et sur une Gentoo, dans le premier cas, il y a rarement d'erreur et ça fonctionne directe, alors que sur gentoo, j'ai plus souvent des erreurs (la plus part du temps corrigeable) et des problèmes d'instabilité pour des versions souvent moins à jour.

      Ce ne sont pas des packages qui me manque, mais une réactivité de mise à jour genre evolution 2.2 qui a été super long à être intégré, comme tout le groupe gnome 2.10, souvent je refait mes ebuilds perso à partir des anciens afin de mettre à jour des paquets en attendant la version officielle. (OOo2-beta par exemple à l'époque), et les packages mettent de plus en plus de temps avant de rentrer dans portage : evince par exemple.

      Pour gcc, la même que debian ou mandrake, ou beaucoup de distrib proposant plusieurs versions de gcc, mais qand on parle de distribution source ou de BSD, il y en a forcément 1 officiel qui sert à la génération des packages, mais gentoo ne permet pas d'en faire cohabiter plusieurs en parallèle, il faut choisir à coup de gcc-config celui que l'on veut et il fonctionnera pour tous les appels à gcc. Alors que concerver ce comportement mais permettre aussi une installation en parrallèle invoqué par la commande gcc40 par exemple alors que la commande gcc concerve le compilo officiel.

      Il n'y a pas de useflags dans FreeBSD c'est vrai, mais il y a des options de compilation via des menus ou des variables d'environnement définissable dans le make.conf pour le choix des dépendances pour beaucoup de packages donc c'est similaire, même si c'est poussé à l'extrême ou presque dans Gentoo (ce qui me plait.)

      • [^] # Re: càd ?

        Posté par  (site web personnel) . Évalué à 4.

        Je viens de comprendre mes erreurs... déjà c'est vrai que je ne teste les paquets en ~arch qu'au compte goute, tu a forcément raison quand tu dit qu'ils sont de moins bonne qualité.

        Et en plus, j'ai cru que gcc se comportait comme tu le décrivais à cause d'un executable gcc32 sur ma machine, que j'ai compris comme "gcc 3.2" alors qu'il n'était que "gcc 32 bits".

        Ça m'apprendras à réflechir avant de parler... désolé.

  • # C'est en effet plutôt grave...

    Posté par  . Évalué à 7.

    Si Jane tousse et souffle, il faut qu'elle aille vite voir le docteur...

  • # Concernant KDE 3.4

    Posté par  . Évalué à 2.

    Il s'agit apparemment de problème de segfault dans quelques applications (au moins Kasteroids) lorsqu'elles sont compilées avec l'option -fvisibility=hidden de gcc (cette compatibilité avec cette option est la principale nouveauté de KDE 3.4, et comme il l'était évoqué dans un autre journal, permet à KDE de gagner en rapidité)

    Il s'agit d'une methode d'une classe du toolkit KDE dont le code est visiblement non compatible avec cette option.

    Le problème est connu en upstream et pour les developpeurs de Gentoo leur seule solution est pratiquement de sortir une ebuild sans l'option fvisibility=hidden.. En fait ils voudraient presque que KDE 3.4.1 sortent rapidement, résolvant ce problème, leur évitant de backporter du code du svn KDE via un patch.

    Bon c'est en tout cas ce que j'ai pu tant bien que mal comprendre à partir de ce rapport de bogue:
    http://bugs.gentoo.org/show_bug.cgi?id=86898(...)

Suivre le flux des commentaires

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