Sortie de la Red Hat 7.3

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
1
6
mai
2002
Red Hat

La distribution RedHat vient de sortir la version 7.3 de sa distribution. Son nom de code est valhalla.



Elle est notamment disponible sur le miroir free.



Note du modérateur : cela ne concerne que la version x86. Avec KDE 3.0, GNOME 1.4, Evolution, Nautilus, XFree 4.2, démarrage accéléré, USB 2, meilleur support des caméras numériques, noyau 2.4.18, gcc 2.96-RH, glibc 2.2.4, Mozilla 0.9.2 0.9.9, OpenMotif 2.1.30, Perl 5.6.1, Apache 1.3.23-9

Aller plus loin

  • # autres mirroirs

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

    ftp://tux.u-strasbg.fr/redhat/7.3/(...)

  • # Euh non, pas le mirroir de free

    Posté par  . Évalué à 10.

    Il est pas à jour, ne l'utilisez pas, il est toujours fermé, dailleurs, on peut pas se connecter.






    Laissez moi télécharger tranquilement d'abord.

    AU fait, ils se sont trompé sur RH.com, c'est un mozilla 0.9.9 qui est dedans (avec le galeon 1.2.0 correspondant pour les amateurs, et je sais qu'ils sont nombreux).

    cf liste des packages :
    http://www.redhat.com/software/linux/pl_rhl.html(...)

    • [^] # Re: Euh non, pas le mirroir de free

      Posté par  . Évalué à 10.

      Et gcc 3.0.4, ils le considèrent toujours pas comme stable? A mon avis, va encore y avoir des flamewars sur gcc-2.96. Au fait, ca veut dire quoi concrètement "démarrage accéléré" ?

      • [^] # Re: Euh non, pas le mirroir de free

        Posté par  . Évalué à 10.

        Désolé mais la RedHat 7.2 (et donc aussi la 7.3) st fournit avec 3 versions de GCC: gcc 2.91.66 pour compiler le noyau et pour la compatibilité avec les RedHat 6.x gcc 2.96 la version officiel pour la série 7.x gcc 3.0.4

        • [^] # Re: Euh non, pas le mirroir de free

          Posté par  . Évalué à 10.

          gcc 2.91.66 pour compiler le noyau et pour la compatibilité avec les RedHat 6.x Cela fait longtemps que egcs 1.1.2 n'est plus utilisé pour builder les kernels quand même. De nos jours, c'est plus parti pour gcc >= 2.96-RH. Sur Itanium notamment, le compilo recommendé est bien gcc-3.0.X. Par contre, gcc-3.1.X pour le kernel, ben faut voir, modulo fixes au kernel. ;-) Quoique les kernels x86-64 sont buildés avec gcc-3.1. cf. http://www.x86-64.org/

        • [^] # Re: Euh non, pas le mirroir de free

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

          Désolé mais la RedHat 7.2 (et donc aussi la 7.3) st fournit avec 3 versions de GCC:

          Eh bien apparemment non, la 7.3 n'a que le gcc 2.96 (2.96-110).

          (ou alors ils ont bien caché les autres gcc ...)


          $ find disc? -name '*gcc*'
          disc2/RedHat/RPMS/gcc-2.96-110.i386.rpm
          disc2/RedHat/RPMS/gcc-chill-2.96-110.i386.rpm
          disc2/RedHat/RPMS/gcc-c++-2.96-110.i386.rpm
          disc2/RedHat/RPMS/gcc-g77-2.96-110.i386.rpm
          disc2/RedHat/RPMS/gcc-java-2.96-110.i386.rpm
          disc2/RedHat/RPMS/gcc-objc-2.96-110.i386.rpm

      • [^] # Re: Euh non, pas le mirroir de free

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

        Au fait, ca veut dire quoi concrètement "démarrage accéléré" ? Concrètement ça consiste à ralentir la procédure de démarrage par adjonction de services plus ou moins inutiles (kudzu, serveur de polices X avant le démarrage de celui-ci, etc.) puis à les supprimer dans les prochaines versions pour dire qu'on a accéléré le démarrage... Ca ne vous rappelle pas quelqu'un ? (indice: ses initiales: MS)

        • [^] # Re: Euh non, pas le mirroir de free

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

          quand même, faut pas être si pessimiste ;-) Il y a eu tellement de nouveauté plus ou moins utiles et qui prenait si peu (temps et mémoire) au démarrage... on les a tous mis par défaut... Après tout, on est tous content d'avoir tous les petits démons en route (serveur mail, http, base de données et j'en passe). Donc arrivé à un moment, ça devient vraiment très très gros à charger... Donc il faut trouver une solution... Mais de là à dire que c'est comme chez MS... (d'ailleurs, chez eux, les trois quarts, on ne peut pas les enlever).

          • [^] # Re: Euh non, pas le mirroir de free

            Posté par  . Évalué à 3.

            "...on est tous content d'avoir tous les petits démons en route"

            Non! Moi, j'ai jamais aimé! C'est clair que ça ralenti le démarrage ; mais AUSSI LE SYTEME ENTIER (ne serait-ce que parce que il y moins de ram libre, donc moins de buffers, etc.)

            Je les sélectionne soiogneusement (si si!) et j'accèlere mon démarrage comme un grand!

            • [^] # Re: Euh non, pas le mirroir de free

              Posté par  . Évalué à 10.

              Puisque l'on en est dans les script de démmarage, ne pas oublier La modif qui change tout dans le fichier /etc/rc.d/init.d/functions, la fonction echo_success :



              echo_success() {
              [ "$BOOTUP" = "color" ] && $MOVE_TO_COL
              echo -n "[ "
              [ "$BOOTUP" = "color" ] && $SETCOLOR_SUCCESS
              echo -n $"\\o/"
              [ "$BOOTUP" = "color" ] && $SETCOLOR_NORMAL
              echo -n " ]"
              echo -ne "\r"
              return 0
              }

            • [^] # Re: Euh non, pas le mirroir de free

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

              Mais c'est par ce que t'es un grand...

              Mais imagine le petit débutant... il ne sait pas trop quoi choisir, donc c'est bien pratique de l'emmener dans le droit chemin (surtout qu'après l'installation, il ne sait pas nécessairement où il faut aller pour réactiver ce qu'il a désactivé).

    • [^] # Re: Euh non, pas le mirroir de free

      Posté par  . Évalué à 10.

      cf liste des packages : www.redhat.com/software/linux/pl_rhl.htm cai nul y a meme pas wmcoincoin et frozen-bubble

  • # Version de gcc

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

    Le choix de la version de gcc a été pour gcc 2.96, alors que la derniere version est la 3.0.4; qqun pourrai m'expliquer l'utilité de ce choix ?? Meme si il est vrai que ce n'est pas propre a RedHat: Mandrake 8.2 a aussi gcc2.96, mais avec gcc3.0 (qqun pourra aussi me dire quelle est la version par defaut ?)

    • [^] # Re: Version de gcc

      Posté par  . Évalué à 10.

      Le choix de la version de gcc a été pour gcc 2.96, alors que la derniere version est la 3.0.4; qqun pourrai m'expliquer l'utilité de ce choix ?? La version de compilo ne change pas d'une release à une autre (identique sur toutes les 7.X). Il faudra donc sûrement attendre la RedHat 8 pour avoir un gcc 3.X

      • [^] # Re: Version de gcc

        Posté par  . Évalué à 10.

        Toutafé, parceque passer à gccd3 par défaut, c'est pas juste changer les paquets du compilateur, c'est surtout reconstruire toute la distribution avec ce compilateur, avec toutes le travail en validation que cela signifie.

    • [^] # Re: Version de gcc

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

      A noter que redhat fournissait gcc 2.96 et gcc 3 avec la RedHat 7.2, mais gcc 3 n'était pas le compilateur par défaut. Il en sera surement de même avec la 7.3, ce qui permet à ceux qui le veulent d'utiliser gcc 3 et à RedHat de garder gcc 2.96 dans la série des 7.x

    • [^] # Re: Version de gcc

      Posté par  . Évalué à 10.

      il y a 4 raisons (je crois) pour incrementer un numero majeur de version de distribution : - une nouvelle version de kernel ( 2.2 -> 2.4) - une nouvelle glibc plus ou moins incompatible a vec la precedente. - un nouveau compilo par defaut (2.96 -> 3.0) - un systeme de packetage different rpm 3.x -> 4.x Dans tous les cas, il faut TOUT recompiler et TOUT reverifier bien bien ... Aussi on ne le fait que si c'est vraiment necessaire. Dans le cas present, comme pour Mdk8.2 ce n'etait absolument pas le cas. donc on ne bouge pas. on reste a gcc 2.96.

      • [^] # Re: Version de gcc

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

        - une nouvelle version de kernel ( 2.2 -> 2.4) Je ne crois pas qu'il y ait besoin de tout recompiler lors d'un changement de version majeure du kernel (2.2->2.4). Seuls certains utilitaires très près du kernel (modutils, ...) sont à mettre à jour.

        • [^] # Re: Version de gcc

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

          Il ne dit pas qu'il faut tout recompiler, mais que cela entraine un changement de version important (genre 7.x->8.x)

        • [^] # Re: Version de gcc

          Posté par  . Évalué à 8.

          Peut etre pas tout recompiler pour un changement de kernel, mais tout reverifier ca surement ! De plus le changement de kernel est l'une des rare justification a la fois "marketing" ( si on peut parler de marketing pour linux ...) et technique pour passer a une version superieure. On peut choisir de passer a Mdk 9.x pour passer a Kde3, mais je vois mal Mdk passer a 9.x en disant "La nouvelle Mdk avec la nouvelle Glibc"... Perso , j'upgrade une machine deja configuree, sans trop de soucis quand il y a incrementation de version mineure. Par contre en cas de changement de version majeure , je prefere carrement faire un backup de /home et /etc et refaire une installation propre. C'est plus long , mais ca evite bien des soucis. Donc je m'attend a ce que RedHat , Mdk, ... ne changent de version majeure que quand ca en vaut vraiment la peine !

          • [^] # Re: Version de gcc

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

            C'est plus long, mais ca evite bien des soucis. Je ne dirais pas ça... par ce que franchement, chez moi, c'est plutot le contraite, une update est beaucoup plus long qu'un formatage et installation. En plus, la sauvegarde, si tu veux etre sur de garder tes données, tu doit la faire, meme avant une update... Donc c'est pas sur ça que tu gagnes du temps. Donc je m'attend a ce que RedHat , Mdk, ... ne changent de version majeure que quand ca en vaut vraiment la peine ! C'est surement ça... et surtout, quand ça leur dit...

            • [^] # Re: Version de gcc

              Posté par  . Évalué à 8.

              La bonne idée est d'avoir un /home et un /etc sur une partoche différente du /

              Par contre, réinstaller tout son system fait que l'on perd tout les logiciels qu'on a installés et qui sont pas dans la distrib. Et même si c'est rapide à reinstaller, c'est jamais ausi rapide que de les conserver.

              • [^] # Re: Version de gcc

                Posté par  . Évalué à 4.

                dans le même genre tu peux installer tous tes logiciels hors distribution dans une partition que tu nomme /usr/local ou /opt. Dans ce cas, il vaut mieux tout faire en statique pour être indépendant des modification de librairie qui interviennent entre les versions ou alors conserver les sources (dans /usr/local/src ;).

                A+

                • [^] # Re: Version de gcc

                  Posté par  . Évalué à 4.

                  Il me semble que tu mets le doigt sur le probleme de ta proposition :)

                  Soit tu compiles tout en statique, soit finalement il est problème qu'après une mise à jour, la plupart de ton /usr/local ne vaille plus un cachou.

                  Le problème, c'est tout en statique c'est plus lourd... et tu perds 'intéret de la mise à jour. Quand tu mets à jour la glibc avec un correctif de bug, ton but est que tout les logiciels utlisant la glibc bénéficient de ce correctif.

                  • [^] # Re: Version de gcc

                    Posté par  . Évalué à 5.

                    A la base je suis d'accord avec toi aucune méthode n'est parfaite et en particulier celle que je décrit n'est parfaite mais :

                    - l'interêt des distributions comme RedHat, Mandrake, ... est qu'il est possible (parfois difficilement certes) d'évoluer entre les version mineures sans que la "structure" n'évolue trop (glib plus ou moins constante, gcc idem, binutils idem,...c'est-à-dire des revision "bug fixe" sur ces paquet essentiels (sinon pourqoui dire GNU/Linus ;)) ce qui permet de faire des binaires statiques de taille raisonnable (en excluant des dépendances vers les libs les plus fondamentales) mais qui ne dépendent pas des "petites" libs (style libpng 2->3). Si cette règle existe il est clair que les exceptions sont nombreuse ;).Tu ne perd pas vraiment l'interêt de la mise à jour car les programmes que je place dans la partition /usr/local ne sont légions ( actuellement j'ai 6 à 7 programmes) et je concéde qu'il serait simple de suivre l'évolution avec les mise à jour mais la paresse est mère de tous les vices ;). De plus, je fais particulière attention à limité le chaînage statique qu'à des libs moins importante que glib, ... pour profiter de tous les avantages qu'une mise à jour apporte en terme de sécuité, stabilité et vitesse

                    - J'y place aussi tous mes script d'administration et de contrôle pour ne pas avoir à les refaire tout le temps.

                    - lorsque l'envie se fait trop pressante de changer de distribution, la partitions me sert aussi de stockage : on y retrouve l'ensemble des répertoires ce qui simplifie le rangement (oui je sai tar est là pour ça mais c'est pas un bon collègue alors).

                    - ça permet de stocker tous les programmes non libres sans qu'il ne soient trop affecté par la mise à jour (par exemple Audiogalaxy, VariCAD, ...)

                    - ça permet de foutre le bordel dans une arborescence sans plier la structure de l'ordinateur (exemple installation de E17)

                    Mais on s'éloigne du sujet là je crois.

                • [^] # Re: Version de gcc

                  Posté par  . Évalué à 3.

                  Sinon une autre possibilite est d'utiliser une distrib comme debian ou gentoo pour pouvoir facilement mettre ses logiciels a jour regulierement.

                  Par contre il faut mieux avoir une connexion haut debit...

                  • [^] # Re: Version de gcc

                    Posté par  . Évalué à 7.

                    Malheuresement pas tous les logiciels que j'utlise ne sont mis en paquet disponibles pour une distribution (style E17, scilab, ...) voire (et la je me cache) libre (ex. Audiogalaxy), alors les mises à jour .....

    • [^] # Re: Version de gcc

      Posté par  . Évalué à 6.

      gcc 3 apporte pas mal de gros changements par rapport à la version 2, et un bon nombre de logiciels ne supportent pas encore toutes ses (nouvelles) fonctionalités.
      Un exemple (totalement au hasard bien sur :)): la glibc. Il faut la 2.2.5 pour avoir un bon support de gcc 3 (et encore, en lisant le changelog , il y a l'air d'avoir encore pas mal de boulot).

      gcc 3 apporte effectivement son lot de (tres) bonnes choses (je pense en particulier au c++), mais les reprcussions sont loin d'etre anodines...

      Evidemment, ca ne doit pas vous empecher de l'utiliser qd meme :)

    • [^] # Dans le même genre

      Posté par  . Évalué à 9.

      Y'a /usr/bin/python qui est toujours python 1.5.2 alors que la 2.2 est stable de chez stable.

      Mais RH utilise bcp de scripts et extension python qui ne se buildent qu'avec la 1.5.2. Du coup tu peux pas mettre python2 en tant que python. Et la ca fait chier pour pas mal de scripts qui n'utilisent pas distutils (le système de package python).

      Ca va puer le gros patch pour gnome2, qui nécessite obligatoirement python2...

      • [^] # Re: Dans le même genre

        Posté par  . Évalué à 3.

        Logiquement il suffit d'installer un paquet python2-2.x.x qui ne crée pas de conflit avec le python-1.5.

        Si ça se trouve c'est ce qu'ils ont fait. Sinon c'est un peu ridicule.

        • [^] # Re: Dans le même genre

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

          Logiquement il suffit d'installer un paquet python2-2.x.x qui ne crée pas de conflit avec le python-1.5.

          oui c'est le cas, mais /usr/bin/python c'est le 1.5, pas le 2.2, d'où mécontentement de certains ...

        • [^] # Re: Dans le même genre

          Posté par  . Évalué à 1.

          Ca ils l'ont fait (et même en compilant avec un prefix /usr/bin ca marche).

          Normalement il n'y a pas de problème, car en python on utilise distutils, qui reconnait la version de python pour laquelle tu installes le paquets. Le problème c'est qu'il y a pas mal de (vieux) modules qui n'utilisent pas distutils (malgré qu'ils soient pour python2) et qui attendent un python en >2.

  • # Update via FTP ?

    Posté par  . Évalué à 4.

    N'y a t'il pas un moyen de faire une mise à jour directement via FTP sans downloader les 2 ISOs (minimales) ?

    • [^] # Re: Update via FTP ?

      Posté par  . Évalué à 10.

      t as autorpm pour ce genre d'upgrade (dispo ici http://www.kaybee.org/~kirk/html/linux.html) je l ai deja utilise pour passer d'un RH 6.2 a 7.0 puis 7.1 sans probleme, faut juste faire attention au choix des packages a ne pas upgrader (le kernel notamment ...)

    • [^] # Re: Update via FTP ?

      Posté par  . Évalué à 10.

      avec apt-get rpm , surement mais faut l installer , le configurer et trouver une source redhat 7.3 "aptgetable" ou alors ramener tous les rpms en local et generer les fichier pour aptget mais ca revient limite a faire "rpm -Fvh *.rpm".

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 8.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # urpmi

      Posté par  . Évalué à 8.

      J'ai utilisé urpmi pour updater ma mandrake 8.1 vers 8.2, essaye ce que ca donne pour une redhat. Il faut chager les medias par defaut, avoir de la place sur le disque dur et du temps. Sinon, j'ai eu droit a quelque surprise, le nouveau paquetage gnome-control-center-plus m'est rester en travers de la gorge. Il fait chier son monde et n'a aucune raison d'exister. Enfin ce sont les joies des updates des distribs.

      • [^] # Re: urpmi

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

        en parlant d'update de la mandrake... J'ai updaté la mienne ce week-end et en passant par l'update, elle prend ~200Mo en plus qu'en la réinstallant proprement en reformatant... (avec les mêmes packages, bien entendu). Quelqu'un pourrait m'indiquer à quoi ils servent ces 200Mo et où ils sont stockés ? Merci d'avance...

        • [^] # Re: urpmi

          Posté par  . Évalué à 6.

          dans /var/cache/urpmi/rpms peut être ?

        • [^] # Re: urpmi

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

          Oui, un fichier de 200Mo dans le /proc ?
          Euh, ça doit être normal :-)

          Axel - 584 (je sors ?)

  • # Red Hat, c'est nul !

    Posté par  . Évalué à -9.

    Et je le prouve : ils ont supprimé enlightenment de leur distro !

    • [^] # Re: Red Hat, c'est nul !

      Posté par  . Évalué à -6.

      Tiens ... http://www.enlightenment.org comme ça tu pourras l'installer tout seul ... comme un grand ...

      • [^] # Re: Red Hat, c'est nul !

        Posté par  . Évalué à -10.

        Heu, je crois que t'as pas très bien lu ma signature, j'ai pas installé une distro depuis trois ans, alors je vais pas commencer avec RedHat :)

        • [^] # Re: Red Hat, c'est nul !

          Posté par  . Évalué à -10.

          De quoi te plains-tu alors ?

          • [^] # Re: Red Hat, c'est nul !

            Posté par  . Évalué à -2.

            Qui parle de se plaindre, il me semble pas avoir émis de plainte. J'ai juste dooner mon avis et une info. Après à vous de l'apprécier à sa juste valeur. Enfin RedHat a jamais été très copain avec Rasterman. Pourtant il fait un chouette code. Alors d'où vient ce choix. Peut être que E, n'est pas assez stable pour eux, ou qu'il n'évolue pas assez vite. Mais au lieu de dire y a ca ca et ca en plus, il pourrait aussi clamer haut et fort que ya ca ca et ca en moins et pourquoi...

            • [^] # Re: Red Hat, c'est nul !

              Posté par  . Évalué à 5.

              Les distributions ne sont pas sensées conprendre tous les logiciels libres créés depuis la nuit des temps. La redhat comporte de nombreux WM ... chacun peut y trouver son compte. Et ceux qui ne sont pas inclus peuvent toujours etre installé pour un cout null. Si redhet ne comprends pas Enlightenment dans cette release ... elle le fera peut etre dans la prochaine version (si enlightenment s'est décidé a sortir sa belle nouvelle version). De plus redhat est plus orienté Serveur ... et enlightenment est plus un WM destiné à en mettre plein la vue ... il n'avait peut etre plus sa place dans cette release ... peut y avoir beaucoup de raison ... il n'empeche que moi , j'le réinstalle de suite.

              • [^] # Re: Red Hat, c'est nul !

                Posté par  . Évalué à -4.

                >De plus redhat est plus orienté Serveur Et plus bas: >il n'empeche que moi , j'le réinstalle de suite Y'a comme une incohérence là. Tu dis que la redhat est plutôt orientée serveur et c'est vrai. Un serveur de production n'est pas supposé être réinstallé sauf accident grave. Ensuite, tu dis que tu vas la réinstaller. Je sais bien que ta machine perso n'est probablement pas un serveur hyper crucial mais si on peu upgrader son serveur, je ne vois pas pourquoi tu ne pourrais pas upgrader ton desktop. Je me demande alors si tu réinstalles parce que la procédure d'upgrade n'est pas fiable et là, ça craint pour une distrib orientée serveur. Comment on fait pour upgrader sans risque et proprement (pas de --force ni de --no-depends) un serveur de production sous redhat?

                • [^] # Re: Red Hat, c'est nul !

                  Posté par  . Évalué à 8.

                  Je pense qu'il parlait de réinstaller E... En outre à part pour des failles de sécurité ou autres bugs, je ne vois pas l'intérêt d'effectuer un upgrade de version sur un serveur qui fonctionne correctement. D'autant que RH possède un excellent système (certes payant mais excellent) de mise à jour en ligne concernant les erratas et autres bugfix...

                  • [^] # Re: Red Hat, c'est nul !

                    Posté par  . Évalué à 2.

                    Oui je parlais de réinstaller E (j'vais tenter la version CVS car elle a l'air pas mal), et l'excellent système de mise à jour est gratuit pour 1 systeme ... donc c'est parfait pour ma machine perso.

  • # Miroirs

    Posté par  . Évalué à 10.

    J'ai (comme d'hab) mis en place une liste de site de téléchargements à jour (et pour la plupart ouverts) ici : http://freshrpms.net/mirrors/valhalla.html Notez aussi que mon reposiroty apt, le package rpm d'apt ainsi que la plupart de mes rpm "faits maison" sont également à jour et prêts pour Valhalla :-) Voir aussi : http://freshrpms.net/ http://apt.freshrpms.net/ Bon téléchargement, Matthias

  • # glibc 2.2.4 (redhat 7.3) vs glibc 2.2.5

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

    C'est bien dommage pour tous les adorateurs de KDE dont je fais parti qu'il n'y ai pas la glibc version 2.2.5 Je m'explique : KDE souffre jusqu'à maintenant d'une lenteur en partie du au linkage avec les librairies dynamiques C++ En juillet dernier est donc sorti objprelink ( http://dot.kde.org/996240227/ ) dont le but etait de vérifier que l'on pouvait réduire le temps de linkage résultat entre 30% à 50% de diminution du temps de lancement des logiciels KDE ! Mais objprelink n'etait pas stable et constituait un galop d'essai Avec la glibc 2.2.5 et les derniers binutils qui contiennent ld, le linkage a été grandement amélioré : * optimizations in the dynamic linker. binaries created by recent binutils versions start up quicker due to reduced time spend on relocations. cf http://www.gnu.org/software/libc/NEWS la version 2.2.5 de la glibc date du 21/01/2002 binutils 2.12 date du 09/03/2002 et ici un utilisateur rapporte cette accélération très importante de KDE grace à la glibc 2.2.5 : http://forum.hardware.fr/forum2.php3?post=9798&cat=11&config=&interface=&cache=&sondage=&owntopic=1&p=1&trash= Si quelqu'un peu confirmer la chose... parceque moi je sens que je vais tester une gentoo recompilée :) un KDE 3.0 + glibc 2.2.5 ca doit être pas mal

    • [^] # Re: glibc 2.2.4 (redhat 7.3) vs glibc 2.2.5

      Posté par  . Évalué à 10.

      Pour info, la glibc de la RH 7.3 est en fait un mix de glibc 2.2.5 CVS et de glibc 2.3 CVS.

      • [^] # Re: glibc 2.2.4 (redhat 7.3) vs glibc 2.2.5

        Posté par  . Évalué à 10.

        Puisque tu as l'air d'être au courant.. Et l'optimisation du linker dynamique (je m'attends à être crucifié par les défenseurs de la langue française), a-t-elle été intégrée dans ce mélange? Parce qu'il disent quand même sur leur communiqué que c'est la version 2.2.4.. --> je susis un peu perdu la.

        • [^] # Re: glibc 2.2.4 (redhat 7.3) vs glibc 2.2.5

          Posté par  . Évalué à 10.

          Et l'optimisation du linker dynamique (je m'attends à être crucifié par les défenseurs de la langue française), a-t-elle été intégrée dans ce mélange? Si tu entends par objprelink, non cela ne l'est pas au niveau glibc, et je n'en sais pas plus à d'autres niveaux. Si tu entends par les optimisations de ld.so naturellement intégrées à partir de la glibc 2.2.5, ben oui. Quand je disais glibc 2.2.5 CVS c'était en fait glibc 2.2.5 + CVS, une sorte de glibc 2.2.6. Mais comme y'a des bouts du 2.3 CVS aussi donc c'est parti pour une glibc-2.2.5-RH comme l'était gcc-2.96-RH. ;-) Parce qu'il disent quand même sur leur communiqué que c'est la version 2.2.4 Tout comme annonçaient-ils Mozilla 0.9.2. C'est bien une glibc-"2.2.5" selon leur liste de packages: http://www.redhat.com/software/linux/pl_rhl.html

    • [^] # Re: glibc 2.2.5 & kde 3.0

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

      Sur une gentoo, c clair, ca arrache au niveau rapidite, non sans mentionner aucun plantage depuis que je m'en sers ! Steph

  • # se surprendre à flipper

    Posté par  . Évalué à 6.

    Un peu flippant ce nom de distrib.. L'endroit où vont les morts dans les légendes nordiques... Je me prend à m'inquiéter... Et si ces noms parlaient de la santé de la boite ... enigma, valhalla... ? Non, allonrs, soyons sérieux, oublions ça... -1

  • # LVM et TROLL

    Posté par  . Évalué à 8.

    RedHat propose lvm (Logical Volume Management). En général, ce qu'il propose est à maturité et c'est une bonne nouvelle pour les developpeurs de lvm ( http://www.sistina.com/products_lvm.htm(...) ) et pour la réputation de Linux dans le monde des serveurs.

    bizarre, il y a peu de critique sur RedHat ici. En général, on trouve beaucoup de pro-mandrake et pro-debian ici. Peut-être que la population linuxfr a changé...

    • [^] # Re: LVM et TROLL

      Posté par  . Évalué à 3.

      A noter que SuSE a inclus LVM depuis pas mal de distributions (la 6.3), avant que ça soit inclu en standard dans le noyau (à partir du 2.4, et même du 2.3.47 pour être précis). Sur la SuSE 6.4 (noyau 2.2.14) il s'agissait de la version 0.8, je l'avais essayée pour voir les perfs (j'avais fait des benchmarks pour ma boîte), la différence de vitesse était notable mais les snapshots marchaient bien déjà. Il faudrait que je refasse des tests avec un noyau 2.4 récent (qui contiendra une version récente de LVM).

      Un papier blanc (c'est quoi la traduc exacte de "white paper" ?) sur LVM (faite par SuSE) est ici : http://www.sistina.com/lvm_whitepaper.pdf(...) (pour ceux qui n'aiment pas la SuSE, ça va vous gratter parce qu'ils collent leur nom souvent dedans, désolé).

Suivre le flux des commentaires

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