Articles précédents : Articles
- [139] Pilotes modem Conexant HCF and HSF désormais payant.
- [143] Le nouveau format de fichiers de Microsoft Office empêche les concurents de lire les documents !
- [32] Un musée des premiers temps
- [27] Nouveau site de documentation : documentation-linux.org
- [19] De la patience, tu dois avoir
- [30] Mobilix perd son procès contre les éditions Albert René.
- [56] IBM (re)fait de la pub pour Linux
- [76] Microsoft conclut un accord à l'amiable avec Be
- [11] Les Trophées du libre sur France Info
- [46] Marché des serveurs sur le 2ème trimestre 2003 : Linux en forte hausse
![[fr]](../../../images/fr.png)
Article (4739 hits)
> Lire la dépêche (70 commentaires, moyenne: 1,5).
Re: Test de la Gentoo 1.4
Effectivement, une distribution très agréable, je l'ai mise sur mon portable.
Comme il n'est pas très puissant, une install GRP est très bienvenue. En ce qui concerne l'install de KDE en GRP, elle marche très bien, mais il ne faut pas utiliser la ligne indiquée dans la doc, qui comme dans l'articla nécessite des packages compilés et source... Il faut utiliser :
# USE="bindist" emerge -K kde
Avec un -K majuscule, et non pas minuscule, pour forcer portage a utiliser le package binaire...
-
[+] [^]Re: Test de la Gentoo 1.4
Posté par drac () le 10/09/2003 à 07:38. (lien). Évalué à -2.Je ne comprends pas l'interet d'installer une gentoo en précompiler. Enfin a mon sens c'est perdre l'un des rares avantages de la Gentoo.
-
[^]Re: Test de la Gentoo 1.4
Posté par Frederick Ros (page perso, ) le 10/09/2003 à 07:50. (lien). Évalué à 5.Ben IMHO c'est pratique pour une install rapide ou sur de petites machines .. Un autre gros interet de la Gentoo (enfin de portage plus precisemment) est la selection fine des packages que tu desires installer....
-
[^]Re: Test de la Gentoo 1.4
Posté par Xavier Poinsard (page perso, ) le 10/09/2003 à 08:25. (lien). Évalué à 2.Autant utiliser une Debian...
-
[+] [^]Re: Test de la Gentoo 1.4
Posté par nooky59 () le 10/09/2003 à 09:06. (lien). Évalué à -6.Bah non, car une Debian en instable, tu flingues tout, alors que avec Portage, tu as les dernières versions des softs sans forcêment nuire à l'intégrité de ton système.
-
[^]Re: Test de la Gentoo 1.4
Posté par Arachne (page perso, ) le 10/09/2003 à 10:23. (lien). Évalué à 5.Foutaises, après différentes séries de test et une utilisation intensive, il m'apparait clairement que Gentoo est aussi stable qu'une sid. Et c'est d'ailleurs logique, étant donné que les logiciels sont très à jour et pas encore bien testés dans les deux cas. Elles sont toutes les deux réservés aux "power users", capables de réparer la bête en cas de problèmes.
-
[+] [^]Re: Test de la Gentoo 1.4
Posté par nooky59 () le 10/09/2003 à 12:15. (lien). Évalué à -2.Dans ce cas là d'accord. M'enfin bon, là est donc l'avantage de Gentoo. La version stable contient des logiciels assez récents et fréquemment mis à jour sur le net, là où la Debian traine un peu la patte pour la version stable.
Donc une Debian est très bien en tant que serveur, mais une Gentoo est peut être un peu plus adaptée en Desktop pour être un peu plus à jour.-
[^]Re: Test de la Gentoo 1.4
Posté par EppO (page perso, ) le 10/09/2003 à 15:19. (lien). Évalué à 1.C'est que tu n'as pas compris la politique de Debian. La version stable de Debian ne rajoute aucun paquet et ne met a jour aucun paquet après sa sortie (à part les security fix).
Si tu veux continuer à mettre à jour tes programmes dans des versions plus éprouvées que celles de la sid, c la testing qu'il faut utiliser (future sarge).
-
-
-
-
[^]Re: Test de la Gentoo 1.4
Posté par Frederick Ros (page perso, ) le 10/09/2003 à 09:19. (lien). Évalué à 4.Ah bon ? Elle supporte un equivalent des USE flags ?
-
[^]Re: Test de la Gentoo 1.4
Posté par Guillaume CASTAGNINO (page perso, ) le 10/09/2003 à 16:00. (lien). Évalué à 2.Les paquets gentoo des 2 CD d'install sont optimisés : personnelement, j'ai utilisé des CD "Pentium 3", ou tous les paquets sont compilés avec -march=pentium3. C'est aussi ce que j'aurais fait si j'avais tout compilé, donc on ne perd pas tout l'interet de la gentoo...
Surtout qu'une debian est compilée pour i386, donc la différence est grande...
Et personnellement, je trouve le systeme portage plus efficace que apt-get...
-
-
[^]Re: Test de la Gentoo 1.4
Posté par RB () le 10/09/2003 à 08:36. (lien). Évalué à 1.c'est peut-être pour recompiler plus tard, mais ne pas avoir à attendre 72 heures avant de pouvoir un tant soit peu bosser avec la machine ?
-
[+] [^]Re: Test de la Gentoo 1.4
Posté par a_jr () le 10/09/2003 à 09:08. (lien). Évalué à -3.c'est peut-être pour recompiler plus tard
Ca, toutes les distributions le permettent. Il n'y a aucune difference entre une debian, une mandraket et une gentoo sur ce point.
La raison est-elle ailleurs, ou se limite-t-elle a dire "moi, j'ai une gentoo" ?-
[^]Re: Test de la Gentoo 1.4
Posté par pyrollo (page perso, ) le 10/09/2003 à 09:39. (lien). Évalué à 0.Est-ce que la Gentoo ne gère pas mieux les dependances qu'une Mandrake ?
Je veux dire par là que la Mandrake ne gère pas autre chose que des packages (dont les dépendances sont parfois bizarres), et quand on compile un programme, il n'est pas pris en compte par le gestionnaire de package. A ce qu'on peut lire sur la Gentoo, elle semble plus intéressante à ce niveau là. Qu'en est-il ?-
[^]Re: Test de la Gentoo 1.4
Posté par Austin () le 10/09/2003 à 10:48. (lien). Évalué à 0.> et quand on compile un programme, il n'est pas pris en compte par le gestionnaire de package.
Les dépendances sont définies à la construction du paquet (à la compilation). De plus rpm fait la detection automatique des librairies utilisées (rpm -q --requires -p toto-1.0-1.i386.rpm => Requires glibc... automatiquement).
> A ce qu'on peut lire sur la Gentoo, elle semble plus intéressante à ce niveau là. Qu'en est-il ?
Pour la gestion des dépendances ? Non, je ne crois pas.-
[^]Re: Test de la Gentoo 1.4
Posté par Brice Arnould ( un_brice ) (page perso, ) le 10/09/2003 à 12:44. (lien). Évalué à 4.> De plus rpm fait la detection automatique des librairies utilisées
càd qu'il gère l'héritage des dépandances? Merveilleux.
Ou alors il analyse le binaire pour déterminer quelles libs sont nécessaires... pas tellement utile non plus.
>Pour la gestion des dépendances ? Non, je ne crois pas.
Les SLOTs (aka possibilité de considérer plusieurs version d'un même soft comme étant des logiciels diffèrents à installer en paralèle (QT, GTK...)).
Des masques au niveau des spécifications des dépendances.
La possibilité d'écrire des ebuilds de trois lignes pour la dernière bidouille amusante trouvée sur le net.
Des packages virtuels (genre "virtual/jvm" pour spécifier toutes les jvms complètes).
Et surtout, les USE flags qui influent sur les dépendances des softs (eg. on peut compiler xmame avec ou sans l'option x11 et ça change les dépandences).
Et pis, franchement, quand on "crois" juste; vaut mieux ne rien dire, surtout quand le sujet est trollogène.--
Respect à RMS.-
[^]Re: Test de la Gentoo 1.4
Posté par a_jr () le 10/09/2003 à 12:51. (lien). Évalué à 2.Et pis, franchement, quand on "crois" juste; vaut mieux ne rien dire, surtout quand le sujet est trollogène.
Non, il a bien fait: ca t'a amene a repondre, et ta reponse m'appris quelques trucs.
Pour la peine, [+] a tous les deux. Merci!
Reponse objective = reponse anti-troll
-
[^]Re: Test de la Gentoo 1.4
Posté par Austin () le 10/09/2003 à 14:46. (lien). Évalué à 1.> càd qu'il gère l'héritage des dépandances? Merveilleux.
> Ou alors il analyse le binaire pour déterminer quelles libs sont nécessaires... pas tellement utile non plus.
C'est utile. C'est la librairie avec son numéro de version qui définie la compatibilité et pas autre chose. Sinon c'est de la duplication d'info. En fesant ainsi, tu peux remmoner des paquets les fusionner, etc... Tout ce qui compte, c'est la facilité réellement fournie et non le nom du paquet. L'héritage est aussi utile car il permet de limiter les nombres de dépendances et ne pas tomber dans l'ingérable. Rpm peut aussi définir des dépendances virtuels (style require: kde) ou des dépendances sur des fichiers ou sur une configuration. Par exemple lors d'un passage de ppp à ppp_ng si ppp_ng utilise config(ppp > 2) qui est déjà fourni par ppp-2.5 et que tu mets à jours, tes fichiers de configuration seront conservés. En fait le système de génération des dépendances utilise des plugins et rien ne t'empêche de devopper de nouveaux plugins (par exemple sur les symboles fournis par le noyau pour vérifier si un module noyau peut-être installé et marchera). Il y a quelques mois un plugins pour gérer les dépendances perl a été ajouté. Il y a un plugin pour prelink, ainsi rpm peut vérifier un binaires même s'il a été modifié par prelink.
rpm gère aussi les branches de paquets. T'as un gnome-2.2.2 spécifique qui utilise un libgnome-2.2.2 spécifique incompatible avec la branche 2.2, si un gnome-2.2.3 "standard" sort, il n'écrasera pas ta version spécifique mais un gnome-2.2.3 avec tes spécificités (marqués par le tag Epoch) sera un candidat pour la mise à jours.
rpm gére aussi les mises à jours sur plusieurs paquets et non seulement sur un seul. C'est l'ensemble des paquets qui sera évalué pour une mise à jour ou une installation et ce n'est pas fait paquet par paquet. un "rpm -U ppp_ng" pourra remplacer ppp et pppoe. Un "rpm -U ppp_ng pppoe" peut être utilisé pour mettre à jour le paquet ppp alors qu'un "rpm -U ppp_ng" n'est pas suffisant. Rpm gère les paquets absolètes. Rpm offrira dans 1 ou 2 mois la possibilité d'annulé la dernière transaction d'installation/mise à jours (c'est un transaction car rpm fait l'opération sur plusieurs paquets qui forme un tout).
> Les SLOTs (aka possibilité de considérer plusieurs version d'un même soft comme étant des logiciels diffèrents à installer en paralèle (QT, GTK...)).
Comme rpm. S'installation en parallàle ne pause pas de problème. Du moins lorsqu'elle est prévus. C'est une pratique très courrante.
> Et pis, franchement, quand on "crois" juste; vaut mieux ne rien dire, surtout quand le sujet est trollogène.
J'en suis sûre.-
[^]Re: Test de la Gentoo 1.4
Posté par tgl () le 11/09/2003 à 01:20. (lien). Évalué à 3.«C'est la librairie avec son numéro de version qui définie la compatibilité et pas autre chose.»
T'as pas dû souvent en écrire des spec de pacquets toi.
«Tout ce qui compte, c'est la facilité réellement fournie et non le nom du paquet.»
J'aurai dis «et non le nom du truc dont on dépend». Ce qui sous Gentoo correspond par définition à la notion de paquet virtuel (genre si on a besoin d'un driver alsa ("virtual/alsa"), on peut se satisfaire soit d'un kernel 2.5/6, soit du driver pour les 2.4).
«L'héritage est aussi utile car il permet de limiter les nombres de dépendances et ne pas tomber dans l'ingérable.»
Je ne vois pas ce que tu veux dire, mais si c'est juste que si "A dépend de B et C" mais que "B dépend aussi de C" alors on peut se contenter de dire que "A dépend de B" (enfin bref pas lister systématiquement tout jusqu'à la glibc), et que ça qu'est génial c'est qu'on peut dire "installe A" et qu'il t'installera les trois, bah c'est pas vraiment un scoop, et je connais pas de système de paquets qui gère pas au moins ça. (Enfin si, je sais plus si rpm le fait, ou le faisais à une époque lointaine en tout cas, ou si c'est urpmi qui le rajoute).
«Rpm peut aussi définir des dépendances virtuels (style require: kde)»
Je sais pas dans le monde .rpm, mais dans le monde .deb c'était plutôt ce qu'on appelait des meta-paquets. Rien à voir avec la notion de paquet virtuel sus-citée.
«des dépendances sur des fichiers»
on en reviens au bon vieux nom/emplacements bien connus. Franchement, je préfère de loin l'abstraction des virtuals (tu fait comment avec un nom de fichier pour dire: un codec divx ?)
«tes fichiers de configuration seront conservés»
Bah manquerai plus que l'install d'un paquet t'écrase ta config existante? Sérieux, c'est encore vraiment la base. (Et la je commence à flipper en me disant que si tu nous les fait tous comme ça je suis pas couché.)
«En fait le système de génération des dépendances utilise des plugins et rien ne t'empêche de devopper de nouveaux plugins»
"inherit plugin" dans un ebuild (Ah nan merde, ça concerne pas que les dépendances mais ça permet de surcharger n'importe quelle methode et d'en définir de nouvelles utilitaires...)
«par exemple sur les symboles fournis par le noyau pour vérifier si un module noyau peut-être installé et marchera»
Faut vraiment être sur une distrib à binaire pour voir ça. C'est merveilleux tellement c'est aller loin contre le bon sens et la simplicité.
«T'as un gnome-2.2.2 spécifique qui utilise un libgnome-2.2.2 spécifique incompatible avec la branche 2.2, si un gnome-2.2.3 "standard" sort, il n'écrasera pas ta version spécifique mais un gnome-2.2.3 avec tes spécificités (marqués par le tag Epoch) sera un candidat pour la mise à jours.»
Cool, ça vous fait un USE flag. Aller, encore un petit effort, c'est presque ça. Mais gaffe à l'explosion combinatoire: 2^(nbre de USE flags) est exponentiel en le nombre de USE flags. Ça va en faire des versions spécifiques à compiler pour RedHat.
«rpm gére aussi les mises à jours sur plusieurs paquets et non seulement sur un seul.»
Ouahouuu!
«Rpm gère les paquets absolètes.»
Pur narcissisme.
«J'en suis sûre. »
Moi je suis sûr grâce à ton post que bientôt rpm aura rattrapé son retard sur apt. Encore qlqs amélioration (vrais paquets virtuels, héritage entre specs, gestion explicite des masques de paquets, mélange aisé de 3 niveaux de stabilité des paquets, système de merge des fichiers de conf, etc), et il sera au niveau de portage pour ce sur quoi il est raisonnable de les comparer. Mais il n'approche qu'à peine (et c'est bien normal, mauvais choix, mauvais résultats) la souplesse que peut offrir un système basé sur les sources (use flags, optimisation, drivers, etc.). Et je n'ai pas parlé d'un autre avantage des ebuilds: le système est tellement simple, et la nécéssité de compiler étant de toute façon là, qu'il devient très vite naturel de modifier un peu l'existant à sa sauce, de se faire ses propres révision bumps, d'écrire des ebuilds nouveaux plutôt que de make installer dans /usr/local, etc. De ce que je vois sur le forum, ou je passe un peu de temps, le "PORTAGE_OVERLAY", c'est à dire ton repository d'ebuilds persos, est une chose connue et utilisée par la quasi totalité des utilisateurs, au moins ponctuellement. Alors que franchement, sur une distrib à la redhat, c'est quoi la proportion d'utilisateurs qui ont un jour fait leur propre srpm ?-
[^]Re: Test de la Gentoo 1.4
Posté par Austin () le 11/09/2003 à 05:00. (lien). Évalué à 0.> Ce qui sous Gentoo correspond par définition à la notion de paquet virtuel (genre si on a besoin d'un driver alsa ("virtual/alsa"), on peut se satisfaire soit d'un kernel 2.5/6, soit du driver pour les 2.4).
Pour en revenir au librairies, si le binaire définit les librairies qu'il a besoin, il vaut mieux avoir un système automatique pour détecter les dépendances avec les librairies que de faire ça à la main. Mais puisque ça te plait, tu peux faire des paquets avec :
requires|provide : "virtual/alsa".
Mais "virtual/alsa" ne dit pas que le paquet ne peut marché d'avec un Linux > 2.4.17 ou < 2.4.21 car une api a changé ou qu'il faut que les fontionnalité real-time soient disponibles ou plus simplement que le module soundcore soit présent. Seulement "virtual/alsa" est de la gestion de dépendance à la petite semaine.
Puis pour les services rendus par plusieurs paquets il y a aussi des facilités virtuels.
exemple :
$ yum provides ftpserver
Available package: vsftpd proftpd wu-ftpd provides ftpserver
> Enfin si, je sais plus si rpm le fait, ou le faisais à une époque lointaine en tout cas, ou si c'est urpmi qui le rajoute
C'est rpm qui le fait et non urpmi/etc. Par rapport à urpmi/apt/yum , rpm est un outil bas niveau et ne fait pas de recherche de paquet pour respecter les dépendances (c'est le boulot d'apt/urpmi/...). Par contre si les dépendances ne sont pas respectées, l'installation/mise_à_jour est refusée par rpm. C'est à urpmi/apt/yum de rechercher les bons paquets suivant des critères retourné par rpm et de les proposer à rpm qui fait tous les contrôles et l'installation (ce que ne fait pas urpmi/apt/...). Ainsi un "yum remove gtk+" fera un "rpm -e --test gtk+" pour connaitre les paquets qu'il faut desinstaller pour supprimer gtk+. (question : il se passe quoi si tu demandes la suppression de gtk+ sur une gentoo ?)
Il faut noter qu'urpmi ou yum sont des petits projets par rapport à rpm. rpm est 20 à 30 fois plus gros que yum ou urpmi qui utilise rpm alors que les gens n'ont d'yeux que pour urpmi/yum/... C'est les facilités de rpm qui permettent ça. Yum ou urpmi, des équivants d'apt mais dédiés rpm, font dans les 5 000 lignes de code seulement.
> Je sais pas dans le monde .rpm, mais dans le monde .deb c'était plutôt ce qu'on appelait des meta-paquets.
Dans la pratique, c'est peu utilisé avec rpm :-). Mais c'est présent (voir plus haut).
Puis que "meta-paquet" ça te plais, il te suffis de faire un paquet vide avec uniquement des "require: ..." et t'as un "meta-paquet".
> Franchement, je préfère de loin l'abstraction des virtuals (tu fait comment avec un nom de fichier pour dire: un codec divx ?)
Si c'est un librairie, tu ne fais rien.
Si la detection automatique n'est pas satisfesante (par exemple plusieurs nom de librairie pour la même fonctionnalité) tu fais une dépendance "virtuel"
"require : codec_divx >= 4".
Un paquet qui fourni cette fonctionnalité a par exemple :
"provide : codec_divx = 4.1".
Tous les paquets rpm on la dépendance vituelle : "provide : %{name} = %{version}"
Tu peux en ajouter autant que tu veux.
Je vois pas pourquoi tu insiste sur le "virtuel".
rpm detecte automatiquement s'il faut libc.so.6(GLIBC_2.3) ou libc.so.6(GLIBC_2.1.3) . Ça n'a rien de virtuel et ça évite bien des conneries. Maintenir en "virtuel" les dépendances avec la librairie C est un véritable enfer. Ma librairie C fournit la comptabilité avec 15 (!) versions (2.0 à 2.3.3). Certains paquets ont besoin de la 2.1.3 d'autres de la 2.3 etc... rpm contrôle tout automatiquement. J'ai vraiment pas envis de renseigner ces informations à main.
> Bah manquerai plus que l'install d'un paquet t'écrase ta config existante? Sérieux, c'est encore vraiment la base.
Tu ne comprends pas. Si un fichier de configuration est déréférences dans la base rpm le fichier est renommé toto.rpmsave (s'il est modifié par rapport à la version de référence). Si un fichier de conf peut-être écrasé il est renommé toto.rpmsave et il y a des options pour ne pas toucher au fichier de config (les nouveaux sont nommés toto.newrpm). Il y a aucun problème avec ça.
Par contre, lorsque rpm ne supportait la gestion des configurations, passer de ppp à ppp_ng (c'est un paquet différent) alors que c'est le même format de fichiers de configuration, aurait créé des .rpmsave (ou .newrpm). Maintenant ce n'est plus le cas.
> C'est merveilleux tellement c'est aller loin contre le bon sens et la simplicité.
Recompilé c'est tellement plus "simple"...
> Cool, ça vous fait un USE flag. Aller, encore un petit effort, c'est presque ça.
Tu ne comprends pas. J'ai rien contre USE qui va "paramétrer" la compilation des paquets et c'est un dispositif très utile. Je parle de la gestion des dépendances. De ce que je comprends, USE n'a rien à voir avec la gestion des dépendances.
Pour rpm on pourrait définir un convention des facilités à utiliser pour compiler un paquet avec "--with qt" ou "--without qt". C'est courament fait.
Exemple :
$ rpm -i proftpd
[...]
Available rpmbuild rebuild options :
--with : ldap mysql postgres tls
$ rpm -i alsa
Available rpmbuild rebuild options :
--without : isapnp sequencer oss
You may also recompile for given cards only by calling rpmbuild with :
--define "cards card1,card2,card3"
(the default is "cards all")
You may also recompile for a given kernel version and arch with :
--define "kernel <uname -r output>"
(for example "kernel 2.4.20-9")
--target
Mais même avec un système pour "châpeauter" la contruction des rpm, ce n'est pas un système de gestion de dépendance. A moins que USE puisse te dire :
- "compilation/installation de KDE refusé car qt n'est pas disponible"
au-lieu de planter au milieu de la compilation.
> Ça va en faire des versions spécifiques à compiler pour RedHat
Je crois que tu n'as pas bien compris le système. D'une certain manière on peut dire que c'est pour avoir des espaces de paquet séparés et éviter les conflits. Imaginons que ximian utilisé un Epoch=12 par exemple, le paquet nommé toto chez redhat ne va pas interférer avec le paquet toto de de xiniam et quelque soit la version des paquets. Par exemple tu ne peux pas mettre à jour libtoto-1.0-1 de ximian par un libtoto-1.0-2 de redhat si le paquet toto réclame un 12:libtoto . Le "Epoch" est prioritaire. L'objectif n'est pas de compiler des 10 façons différentes le même paquet. Il y a d'autres mécanismes pour ça ("--define", "--with", "--without").
> > Rpm gère les paquets absolètes.
> Pur narcissisme.
Exemple concret. Apache fournit maintenant mod_dav alors qu'avant c'était un paquet séparé. Dans le paquet il y a :
Obsoletes: mod_dav
Le nouveau paquet apache est autorisé à supprimer mod_dav puisqu'il le fourni. Sinon rpm indique un conflit (il ne va pas desinstaller un paquet sans "authorisation") et il faut désinstaller mod_dav avant de mettre le nouveau apache.
C'est aussi utilisé pour changer de version de distribution. Si la distribution passe de wu-ftpd à proftpd, il y aura dans proftpd :
Obsoletes: wu-ftpd
wu-ftpd sera supprimé si proftpd est installé. Ce qui est normal si le distributeur ne veut plus supporter wu-ftpd.
C'est aussi grace à ça que les gens passent de Mandrake 9.0 à 9.1 ou redhat 8.0 à 9 sans tout réinstaller.
C'est toujours du "Pur narcissisme" pour toi ?
> Moi je suis sûr grâce à ton post que bientôt rpm aura rattrapé son retard sur apt.
C'est d'une "naïveté"... apt existe pour rpm.
rpm n'est pas l'équivalent d'apt !
up2date ou urpmi ou yum sont des équivalents d'apt. L'équivalent de rpm dans le monde apt est dpkg.
> vrais paquets virtuels
Fait.
> héritage entre specs
???
> gestion explicite des masques de paquets
???
Tu parles peut-être encore de compilation alors que je parle de gestion de dépendance pour un système rpm qui n'est pas orienté source.
> mélange aisé de 3 niveaux de stabilité des paquets
Fait.
> système de merge des fichiers de conf
Fait, c'est les triggers du paquet qui le font. Du moins si le paquet est développé pour le faire.
> Mais il n'approche qu'à peine (et c'est bien normal, mauvais choix, mauvais résultats) la souplesse que peut offrir un système basé sur les sources ... blabla source compilation etc
rpm n'est pas fait pour faire une distribution orienté source. Comparer rpm à gentoo sur ce point n'a pas de sens.
Par contre il est possible de faire une surcouche à rpm pour faire une distribution orienté source. Les binaires stokent le nom du paquet src.rpm qui stockent ce qui est nécessaire pour la compilation qui est elle-même paramétrable via --define --with --without. Une sourcouche pour "piloter" tout ça est tout a fait envisagable.
Mais avec ça on reste loin de la possilité de faire ça depuis les sources :
$ yum install_build_from_source provides libgnomeui-2.so.0
ou
$ yum install_build_from_source provides /usr/X11R6/bin/xscreensaver-demo
Or ça marche avec les binaires et avec résolution des dépendances. A moins de tout mettre en dure (pas de detections automatiques) ça ne peut pas marcher avec les sources. Tout mettre en dure n'est pas une bonne solution si on ne veut pas système bordélique.
> Alors que franchement, sur une distrib à la redhat, c'est quoi la proportion d'utilisateurs qui ont un jour fait leur propre srpm ?
Je fais mes rpm quand c'est nécessaire (ajout crypto, driver adsl, etc). Je préfère utiliser mon système que d'attendre la fin d'une compilation de 10 heures.
Renseigne toi un peu, les repository pour rpm ne manquent pas :
- http://plf.zarb.org/(...)
- http://dag.wieers.com/home-made/apt/(...)
- http://atrpms.physik.fu-berlin.de/(...)
- http://ftp.falsehope.com/pub/(...)
- http://www.fedora.us/index-main.html(...)
- http://home.teleport.ch/simix/(...)
- http://ccrma-www.stanford.edu/planetccrma/software/(...)
- http://freshrpms.net/(...)
- ...
T'as prouvé ton ignorance complète sur rpm.
Si tu veux une distribution orienté source, reste sous Gentoo. Personne n'a dit que les distributions actuelles basées sur rpm étaient des distributions orientées source.
Si les .rpm et .deb sont sur la place depuis un moment, ce n'est pas un hazard et surement pas à cause de "mauvais choix" comme tu dis.
Mais quels "mauvais choix" ? Tu peux t'expliquer ?
Le "mauvais choix" de n'avoir pas mis la priorité sur les distribution orienté source ?
Réjouis toi alors. Ça garanti un succès fulgurant de gentoo. Mais pour quand ? Car la déferlante on ne la voit pas venir actuellement.
-
-
-
-
-
[^]Re: Test de la Gentoo 1.4
Posté par a_jr () le 10/09/2003 à 10:50. (lien). Évalué à 2.Si on prend le cas Mandrake, effectivement, il arrive qu'il y ait des dependances bizarres.
Mais dans le cas general, pour les distributions a base de rpm, et pour debian(je ne sais pas pour les autres), donc mandrake comprise, il y a une gestion des dependances. Et on ne peut pas compiler gtk+ si glib-devel n'est pas installe.
Est-ce que la Gentoo ne gère pas mieux les dependances qu'une Mandrake ?
C'est peut-etre un argument en faveur de gentoo que je ne connais pas trop, mais uniquement par rapport a mandrake. Parce que dans ce cas, je t'oppose debian et ton argument ne tient pas.
Le bonjour chez vous,
Yves-
[^]Re: Test de la Gentoo 1.4
Posté par RB () le 10/09/2003 à 13:12. (lien). Évalué à 0.Honnêtement les distribs comme Mandrake gêrent hyper mal les dépendances par rapport à la gentoo, debian, bsd.
Suffit de faire un test simple (j'ai du faire ça avec la 9.0 ou 9.1). Tu installes le système. Tu te dis chouette, y a le nouveau mozilla 1.3.X en cooker, j'aimerais bien l'avoir. Tu te règles sur le système urpmi cooker. urpmi mozilla. Le machin te propose alors de mettre à jour 500 packages et de downloader 800 Mo (ce sont pas les chiffres exacts mais c'est pour donner un ordre de grandeur => Bref, en gros ton système complet va passer à cooker). En fait, une gestion fine des dépendances verrait très bien qu'il y a pas tant de choses à mettre à jour pour que le nouveau mozilla passe, mais avec la mandrake, les packages sont hyper liés avec ceux qui sont dans la même branche, comme si le programme truc-1.2 ne peut marcher qu'avec le machin-1.2.39 de cooker et pas le machin-1.2.36 de la 9.1. Avant la gentoo j'utilisait la mandrake et je suis passé à la gentoo pour ça, mais je vais remettre la mandrake prochainement et rester synchro en cooker parce que je perd trop de temps en compilation avec la gentoo, vivement les packages binaires. Et pour les packages binaires, la mandrake est la meilleur distrib. Sinon, pour moi la gestion des packages c'est le critère n°1 de mon choix.-
[^]Re: Test de la Gentoo 1.4
Posté par Mjorken () le 10/09/2003 à 14:00. (lien). Évalué à 1.Je pense que tu y verrais un bon compromis avec la Slackware.
Je l'ai utilisé quelques temps, bien qu'au final elle ne me plait pas vraiment, avec Swaret pour upgrader sa distribution ça marche du tonnerre, et t'as plus de contrôle sur ta distrib que sous une Mandrake.
Elle est pas mal à jour aussi, contrairement à une debian stable qui pousse à changer en sid, chose qui, a pas mal merdé chez moi.
Bon par contre pour les dépendances, pas la peine d'y compter mais honnetement, elles ne m'ont pas manqué quand je tournais dessus.
Ce qui me manquais personnellement, c'était la convivialité à la Redhat/Mandrake, même si j'avais reussis à la faire tourner convenablement, sur la longue durée ça m'a vite saoulé pour des petits détails.
Par exemple, j'avais installé Cups et bizarrement, le fichier du service cups ( /etc/rc.d/init.d/cups ) n'avait pas les autorisations d'etre lancé et j'ai passé pas mal de temps avant de comprendre ça. (oui, je dois être con je sais)
Avec un poil plus de convivialité, ce serait la distrib parfaite à mes yeux.-
[^]Re: Test de la Gentoo 1.4
Posté par RB () le 10/09/2003 à 18:37. (lien). Évalué à 1.Ouais... actuellement le top se serait un mélange mandrake-gentoo-redhat.... mandrake est cool parce qu'il y a des tonnes de pkg en urpmi surtout les sources comme plf sont géniales et l'ensemble marche plutot bien (a part que les dépendances sont pas fines). Sinon, la gentoo, a des supers concepts mais la stabilité du système de package c'est pas encore ça et il faut absolument une utilisation des package binaires. Pis redhat, c'est vraiment la distrib la plus finie. Quand on y pense, mandrake fais 15 beta, 12 RC et à la fin y a toujours pas mal de bugs, rehat c'est en général une beta et la distrib est beaucoup mieu finie. Ou ils ont beaucoup plus de testeurs en interne ou ils ont des meilleurs techniques de travail.
Sinon pour la slackware, ce qui me gêne par rapport à la gentoo et la debian ce sont les dernier packages, j'aime bien les derniers trucs, même s'ils sont encore noté beta, comme gimp 1.3 qui est génial. Sous gentoo tu peux facilement installer des choses comme ça. Faudra que j'essaie la debian sid une fois, c peut-être ce qui me conviendrait le mieux. Je dois dire que quand j'était sur debian stable y a quelques années, la vieilles des packages m'avais légérement refroidi.
-
-
-
-
-
[^]Re: Test de la Gentoo 1.4
Posté par Arachne (page perso, ) le 10/09/2003 à 10:41. (lien). Évalué à 5.Non, recompiler son système sous Gentoo n'a rien à voir avec Debian et Mandrake. Je ne vais même pas m'emmerder à décrire le fonctionnement de Portage, si tu t'y étais un peu intéressé tu aurais immédiatement vu les différences.
Ta remarque est vraiment minable et me déçoit de ta part. Gentoo n'a pas séduit les utilisateurs grâce à son nom enchanteur et sa réputation (je ne vois vraiment pas ce que ça a de branché de dire qu'on a une Gentoo), mais bien parce qu'elle est agréable à l'utilisation, parce qu'elle correspond aux besoins de certains, parce que son support est de qualité, et parce que sa communauté est ouverte et active.
Pourquoi est-ce que dés qu'on parle de Gentoo on a systématiquement un crétin qui vient nous emmerder en disant que Gentoo sapu sai de la flambe. Je vous demande, moi, pourquoi vous utilisez Debian, Mandrake, Slack, ou quoi que ce soit d'autres ? Si on utilise Gentoo, c'est parcequ'on la préfère. Point. Laissez nous notre putain de liberté et arrêtez de nous cassez les couilles, bordel!-
[+] [^]Re: Test de la Gentoo 1.4
Posté par a_jr () le 10/09/2003 à 11:01. (lien). Évalué à -3.(je ne vois vraiment pas ce que ça a de branché de dire qu'on a une Gentoo)
Je ne vois pas non plus, d'ou ma question, de savoir si y'a autre chose.
j'ai dit: La raison est-elle ailleurs, ou se limite-t-elle a dire "moi, j'ai une gentoo" ?
Tu me reponds: Pourquoi est-ce que dés qu'on parle de Gentoo on a systématiquement un crétin qui vient nous emmerder en disant que Gentoo sapu sai de la flambe. et pus loin Laissez nous notre putain de liberté et arrêtez de nous cassez les couilles, bordel!
J'espere qu'il y a des gens plus sympas que toi dans la communaute gentoo qui sauront me repondre en deux mots de maniere credible.
En tout cas, avec ta reponse, c'est surement pas comme tu dis parce que sa communauté est ouverte.
Le bonjour chez vous,
Yves-
[^]Re: Test de la Gentoo 1.4
Posté par imr () le 10/09/2003 à 11:28. (lien). Évalué à 3.Vu la question, je trouve assez assez normal qu'il se soit énervé. Elle sous entend clairement qu'une des raisons principales d'utiliser gentoo, c'est la frime, les autres raisons seraient moins évidentes à trouver, seraient ailleurs.
Rien qu'en fréquentant linuxfr.org et sans utiliser la gentoo, je sais que les utilisateurs de la gentoo apprécient dans leur distro, et la communauté trés active, et le fait de savoir toujours ce qu'ils ont installé tout en ayant pu finement géré les options de compilation de ces éléments.
Bref, la fausse naïveté de la question et la pique assez basse qu'elle contenait m'aurait aussi mis hors de moi. Alors en rajouter aprés coup, dans le "j'espére qu'ils sont plus sympas que toi", c'est d'une mesquinerie ébouriffante.-
[+] [^]Re: Test de la Gentoo 1.4
Posté par kesako () le 10/09/2003 à 12:09. (lien). Évalué à -1.non j'ai eu la meme reaction qu'Yves.
Toi tu retorque poliment , mais Arachne l'a insulté : "minable" , "crétin qui vient nous emmmerder", "casser les couilles" ...
Faut pas s'attendre a des fleurs quand on parle de cette facon.
BTW :
> tout en ayant pu finement géré les options de compilation de ces éléments.
justement le post initial dit qu'il ne recompile pas donc ca se ramene a un choix assez subjectif.
-
[^]Re: Test de la Gentoo 1.4
Posté par a_jr () le 10/09/2003 à 12:48. (lien). Évalué à 1.Bref, la fausse naïveté de la question
Comment aurais-je pu demander cela ?
A chaque fois que j'ai demande, on m'a repondu "parce que ca roxor". Comment poser la question pour avoir une reponse digne de ce nom ?
"j'espére qu'ils sont plus sympas que toi", c'est d'une mesquinerie ébouriffante.
je me suis fait qualifier de cretin et maintenant, de mesquin.
C'est vraiment pas encourageant, la communaute gentoo...
Et je reitere ma question: comment avoir une reponse digne de ce nom, et sans me faire appeler cretin mesquin des les premieres reponses ?
Le bonjour chez vous,
Yves-
[^]Re: Test de la Gentoo 1.4
Posté par imr () le 10/09/2003 à 13:26. (lien). Évalué à 2.Pour te montrer un peu plus ton parti pris, relis mon post, je dis que je n'utilise pas la gentoo, mais tu te sers quand même d'un point de ma réponse pour (dé)qualifier sa communauté tout entiére.
Deuxiéme chose, imaginons que je dise dans une news consacrée à debian:
"Ca, toutes les distributions le permettent. Il n'y a aucune difference entre une debian, une mandraket et une gentoo sur ce point.
La raison est-elle ailleurs, ou utilise-t-on debian par elitisme?"
Et qu'ensuite, la bouche en fleur, je m'étonne qu'on me réponde sur un ton énervé et que je dise "ah ben désolé mais chaque fois que je parle à un utilisateur debian, il me répond sur ce ton, c'ets donc bien qu'ils sont tous comme ça".
J'aurais réussi à montrer que mon parti pris entraine ce genre de réponse.
Et si juste aprés ça, j'allais mettre des vannes sur la news mandrake, j'aurais prouvé que je suis exactement ce genre d'utilisateur que je décris.
imr
Bonjour chez toi aussi.
-
-
-
-
[^]Re: Test de la Gentoo 1.4
-
-
-
-
Re: Test de la Gentoo 1.4
Bon comme je ne suis pas prems, je me sens obligé de critiquer ;op
Le premier point est l'absence de lien vers le site de téléchargement de Gentoo. Bien sur, Google est mon ami mais quand on fait un test/article sur quelque chose, il me semble indispensable de dire où trouver ce de quoi on parle.
Le deuxième point ... heu bah à part que je trouve ça trop court, je ne ferai pas mieux alors félicitation ...
-
[^]Re: Test de la Gentoo 1.4
Posté par racoon () le 10/09/2003 à 07:34. (lien). Évalué à 3.Ben au moins pour le premier point, on peut arranger ça avec la liste des miroirs
http://www.gentoo.org/main/en/mirrors.xml(...)-
[^]Re: Test de la Gentoo 1.4
-
-
[^]Re: Test de la Gentoo 1.4
Posté par passant (page perso, ) le 10/09/2003 à 07:38. (lien). Évalué à 4.Bien sur, Google est mon ami
héhéhéhé
http://linuxfr.org/2003/09/06/13846.html(...)
http://linuxfr.org/comments/265858.html(...)
http://linuxfr.org/comments/266012.html(...)
le bonjour chez vous ->[]--
--
-
[^]Re: Test de la Gentoo 1.4
-
[^]Re: Test de la Gentoo 1.4
Posté par Erwan (page perso, ) le 10/09/2003 à 15:41. (lien). Évalué à 3.De toute facon pour une distrib qui ne met pas Gnome et/ou Kde a sa sauce, les screenshots n'apportent pas grand chose.
-
Noyau SMP
Hey Steph
tu dis dans ton article que le noyau SMP n'est pas dispo sur les mini live cd. Je pense que si en fait, il suffit de taper 'smp' a l'invite (lilo si je me souviens bien) a la place de 'gentoo'.
Sinon, très bon article, objectif.
Juste pour revenir dessus encore une fois, j'ai installé sur mon portable un freebsd dont je suis ravi. Les ressemblances avec la gentoo sont flagrantes. Cependant, FreeBSD est quand meme bcp plus à jour que gentoo, qui a un peu de mal ces dernièrs temps a suivre le rythme des sorties de soft.
Pour rappel, le noyau avec patchs gentoo est toujours la 2.4.20 (meme si le 2.4.22 vanilla est dispo bien sur), kde 3.1.3 est dispo depuis deux jours, on a tjrs python 2.2 (le 2.3 est sorti il y a un bon moment), etc.
-
[^]Re: Noyau SMP
Posté par Frederick Ros (page perso, ) le 10/09/2003 à 08:21. (lien). Évalué à 3.Ben :
- vanilla-sources-2.4.22.ebuild
- kde-3.1.3.ebuild
- Python ouaip .. mais bon la 2.3 est sortie fin juillet .. y'en a peut-etre qui ont pris des vacances ..
- vanilla-sources-2.4.22.ebuild
-
[^]Re: Noyau SMP
Posté par FRLinux (page perso, ) le 10/09/2003 à 08:24. (lien). Évalué à 2.euh non non, je te garantie que sur le mini CD que j'ai telecharge, il n'y a PAS de noyau SMP.
Steph
-
[^]Re: Noyau SMP
Posté par drac () le 10/09/2003 à 09:42. (lien). Évalué à 1.>Sinon, très bon article, objectif.
J'aimerai bien que tu m'expliques comment une experience personnelle peut-elle être objective. La subjectivité d'un article n'en diminue pas les qualités, c'est même à mon avis plutot interressant puisque cela permet la diversité ...-
[^]Re: Noyau SMP
Posté par Gentoo][Gravis (page perso, ) le 10/09/2003 à 10:25. (lien). Évalué à 4.Pour lire la ml de gentoo-dev, je sais que Steph (FRLinux) a bcp donné pour gentoo. Quand il en parle, ce n'est pas sur un test de deux ou trois heures, mais une expérience mure.
-
[^]Re: Noyau SMP
Posté par drac () le 10/09/2003 à 12:48. (lien). Évalué à 1.Oui je suis d'accord, il connait certainement bien mieux Gentoo que moi. Mais il faudra qu'on m'explique en quoi ca rends un test objectif. Comme tu le dis: il s'implique dans la chose. Ce qui nous donne un article de quelqu'un qui connait bien Gentoo, ce qui rends l'article d'ailleurs interessant, mais à mon avis son article est subjectif (il donne l'avis de quelqu'un qui connait bien gentoo)
-
[^]Re: Noyau SMP
Posté par Gentoo][Gravis (page perso, ) le 11/09/2003 à 12:52. (lien). Évalué à 1.Tssssssssssssss, je le vois venir ton petit troll mon bonhomme.
Pour etre objectif, un test doit etre fait par un extra-terrestre, et encore, peut-etre meme que seul dieu pourrait le faire.
treve de plaisanterie, si tu te sens de faire meilleur test, ou de trouver mieux ailleurs, lance toi. Dans le cas contrainre, tu prends ce qu'on te donne (et oui Linuxfr, c'est comme la cantine, et t'as interet a finir ton assiette).
-
-
-
Re: Test de la Gentoo 1.4
Bon, je vais dire deux mots sur la gentoo que j'utilise à 100% depuis 4 mois sur 2 machines.
Les fichiers de configs, d'initialisation du système sont un modèle du genre, notamment les dépendances et le lancement synchronisé des services au démarrage. Le reste de etc est très bien fait, avec des petits fichiers de config qui sont ensuite fusionné dans un plus gros comme /etc/modules.conf. Faut juste s'habituer et comprendre ou mettre les choses.
Maintenant la raison principale d'utiliser gentoo est le système de package. Pour ceux qui connaissent pas, on peut dire au système ce que l'on aime et que l'on aime pas genre "qt -gtk alsa -oss" ça s'appelle les USE flags. Théoriquement les applications qui ont beaucoup de dépendances vont adapter la liste des dépendances et les options de compils en fonction de vos préférences. Sinon dans le système de package, il y a la branche 'stable' et expérimentale.
En pratique. Les USE flags a mon avis se multiplient beaucoup et quand il y aura autant de flags que de package ça deviendre inutile. Les USE flags font que chaque personne à pas forcément la même config. Bref, ce que je veux dire c'est que quand même c'est vraiment pas rare qu'un package ne compile pas (même en stable). Alors bon, ce qu'il y a de bien c'est qu'il est possible d'installer plusieurs version d'un même soft, alors quand ça marche pas on peut en essayer une autre... Mais quel est l'avantage des USE flags ? en fait à mon avis, ça introduit plus de problème puisque les packages doivent bien gêrer les différentes possibilité de config et bien compiler dans tous les cas (ce qui n'est pas le cas). En fait, qu'est ce qu'on en a a foutre que mplayer soit installé avec alsa ET oss ? On y perd pratiquement aucune place et aucune vitesse. Bref, je pense qu'il serait mieux que les softs soient compilés avec toutes leurs options, a mon avis on y perdra pas plus d'1% d'espace disque et ça améliorera la cohérence du système et ça pourra faciliter l'arivée de package binaires. Parce que voilà, les binaires, ils ont pas forcément nos options de compils et ils ont pas forcément été compilé avec les même USE que nous, ça donne l'impression de poluer notre beau système bien optimisé. Je dois dire que moi j'aimerais vraiment qu'il y aie des binaires téléchargeables via le système de package et intégré au système parce que ça prend vraiment trop de temps de compiler X, kde, mozilla, ...
Sinon dans ce système, il y a des bonnes idées comme les SLOT qui permettent d'avoir plusieurs versions incompatibles d'une librairie ou d'un programme installé en parallèle.
Bon bref, c'est un système plein de bonnes idées, dynamique, jeune, mais ça veut aussi dire pas super fiable au niveau du système de package. Sinon, comme d'hab, mon système compilé avec toutes mes optimisations ne me semble pas aller plus vite qu'une mandrake ou une redhat.
-
[^]Re: Test de la Gentoo 1.4
Posté par Austin () le 10/09/2003 à 11:01. (lien). Évalué à 1.Pour ma part, je ne vais pas installer une gentoo. Trop "prise de tête" sur certains aspects comme tu le sous-entends pour pas grand chose. Par contre si j'ai besoin d'un système qui prend peu de place j'y jeterai un coup d'oeil.
Je recompile beaucoup plus rarement les programmes qu'avant car ils sont maintenant livrés complets pour la majorité des usages. Et c'est tant mieux.-
[^]Re: Test de la Gentoo 1.4
Posté par Arachne (page perso, ) le 10/09/2003 à 12:21. (lien). Évalué à 3.>> Par contre si j'ai besoin d'un système qui prend peu de place j'y jeterai un coup d'oeil.
Attention: la compilation prend pas mal de place dans /var, le système final peut être minimaliste, mais il faut de l'espace pour le construire.-
[^]Re: Test de la Gentoo 1.4
Posté par Clément varaldi (page perso, ) le 10/09/2003 à 14:55. (lien). Évalué à 1.pour exemple, une compilation de mozilla peut atteindre 4Go. Certes, mozilla existe en package binaire, mais c'est un exemple qui illustre bien que la gentoo peut être gourmande en place
-
[^]Re: Test de la Gentoo 1.4
Posté par RB () le 10/09/2003 à 18:41. (lien). Évalué à 1.J'ai tout compilé avec moins d'1 Go de libre sur le système, c'est impossible que mozilla prenne autant.
Sinon pour gagner de la place vous pouvez effacer dans /var/tmp la ou portage bosse. Sinon de temps en temps /usr/portages/distfiles si vous avez une bonne connection pas besoin de garder des Go de dl sur le disque.
-
[^]Re: Test de la Gentoo 1.4
Posté par Christophe (rOotix) GUILLOUX (Jabber id, page perso, ) le 10/09/2003 à 19:17. (lien). Évalué à 1.j'ai un /var de 2 Go pour la compile, un /usr/portage/distfiles sur nfs de 6Go
-
[^]Re: Test de la Gentoo 1.4
Posté par Gentoo][Gravis (page perso, ) le 12/09/2003 à 16:07. (lien). Évalué à 2.Attention aux "features" que vous utilisez aussi.
Si on met tout par default, oui, ca va prendre un max de place, c'est normal !
ex :
"buildpkg" : ca construit un package binaire, donc ca prend de la place.
[...]
et :
# 'keeptemp' prevents the clean phase from deleting the temp files ($T)
# from a merge.
# 'keepwork' prevents the clean phase from deleting the WORKDIR.
-
-
-
-
[^]Re: Test de la Gentoo 1.4
Posté par Erwan (page perso, ) le 10/09/2003 à 15:48. (lien). Évalué à 1.Pour ma part je trouve qu'un Gentoo est moins prise de tete qu'une distrib binaire ; le seul probleme, c'est qu'il faut le temps pour que ca compile.
Avant je renoncait a installer les dernieres versions des softs car ca forcait a mettre a jour le quart du systeme (comme disait l'autre, pour installer un package mandrake cooker faut presque tout passer a cooker). Ensuite il faut regulierement telecharger 3 isos pour faire une mise a jour complete de 8.0 a 8.1 et se rendre compte finalement qu'on a plus vite fait de formater /, si on a mis /home sur une autre partoche.
Bref, pour moi Gentoo c'est moins prise de tete. Faut juste de temps en temps laisser tourner la bete (mais pas besoin non plus de rester devant son ecran a regarder la sortie de la compilation).-
[^]Re: Test de la Gentoo 1.4
Posté par cmahe () le 10/09/2003 à 17:24. (lien). Évalué à 1.J'utilise la gentoo depuis début Juillet (installé d'abord à partir du CD de Login sur un deuxième disque) : vraiment le pied !
Le système portage est vraiment très bien conçu et permet des mises à jour faciles et toujours de versions très récentes de mes programmes préférés. J'aime bien aussi les scripts de démarrage très clairs.
J'utilisais auparavant une SuSE 6.4 "patché à mort" car le vrai problème avec les SuSE, Mandrake, RedHat et autres ce sont les mises à jour : ainsi avec SuSE je ne pouvait plus installer de nouveaux rpm car le rpm.rpm (!) des nouvelles versions n'était plus compatible avec ma glibc ! Indémerdable, à moins de repasser à la "caisse" (achat d'une la toute dernière version SuSE). Je passais donc souvent directement par les sources mais bonjour les soucis (cf. installation de gnucash par exemple !)
On pourrait déplorer les temps de compilation, mais bon moi la nuit je dors ;-) Je n'ai pas vraiment trouvé ça si terrible que ça ! Et pourtant je n'ai qu'un PIII 667 Mhz + 256 Mo de RAM + DD 60 Go 7200 T.
Le gain en performance est assez peu sensible mais ce n'est qu'un gadget par rapport au reste.
Bref gentoo l'essayer c'est l'adopter !.-
[^]Re: Test de la Gentoo 1.4
Posté par jerome bagattin () le 10/09/2003 à 19:05. (lien). Évalué à 1.> Bref gentoo l'essayer c'est l'adopter !.
Ben non, j'ai découvert Linux avec Redhat il y a quelques années, puis j'ai essayé beaucoup de distribs (aussi bsd et solaris ...) en dual boot avec le home partage pendant plusieur mois, en démarrant une fois sur l'une une fois sur l'autre pour finalement garder celle qui me conviens le mieux. J'ai bien sur essaye gentoo mais elle n'a pas detronee debian !!
Je reproche a gentoo l'obligation d'avoir une station de dev complete qui bouffe beaucoup de place disque (2 Go sur mon portable ) un temps de compil vraiment trop long pour gagner trois fois rien une stabilité inferieure a debian.
Donc j'ai essayé, j'ai aimé mais pas adopté !-
[^]Re: Test de la Gentoo 1.4
Posté par tgl () le 11/09/2003 à 01:49. (lien). Évalué à 2.«Je reproche a gentoo l'obligation d'avoir une station de dev complete qui bouffe beaucoup de place disque (2 Go sur mon portable)»
Ça c'est sûr que faut pas être au giga près si on a pas une autre machine pour les compilations, c'est vraiment inhérent au principe d'une distrib source. En ça je comprends que ça convienne pas à tout le monde. Et il manque vraiment un système moins "manuel" pour le déploiement: genre pas possible pour l'instant de maintenir à jour simplement une gentoo sur un P100 avec 200Go de disque, qui ferait serveur mail, malgré une machine de compil à côté. La notion de cibles (par exemple des machines d'archi différentes, sans portage installé dessus, et sans bien sûr la machinerie de compilation) n'est pas encore intégrée à portage. Tout ce qu'on peut faire facilement avec gentoo pour de telles cibles, c'est une pseudo slackware (on leur prépare des tbz2 quoi, à installer à la main).
«un temps de compil vraiment trop long pour gagner trois fois rien»
Gagner en quoi, en "perf" ? Bah oui c'est clair. Mais en souplesse c'est assez incomparable (use flags, etc.).
«une stabilité inferieure a debian.»
Des détails stp ?-
[^]Re: Test de la Gentoo 1.4
Posté par Brice Arnould ( un_brice ) (page perso, ) le 11/09/2003 à 16:42. (lien). Évalué à 2.genre pas possible pour l'instant de maintenir à jour simplement une gentoo sur un P100 avec 200Go de disque, qui ferait serveur mail, malgré une machine de compil à côté
Je utilisé distcc une fois pour essayer de palier à ce même problème.
Au cas où tu le connaitrais pas, je te le conseille vivement ^_^ (mais je crois pas qu'il gère la cross-compilation).
Pour ce qui est de la remarque sur la stabilité du type auquel tu réponds... j'en profite pour crier:
LES CODES SOURCES DE GENTOO SONT AUSSI CEUX DES AUTRES DISTRIBS ET ON PEUT INSTALLER LES MÊMES VERSIONS (désolé si le bruit dérange les trolls).--
Respect à RMS.
-
[^]Re: Test de la Gentoo 1.4
Posté par jerome bagattin () le 11/09/2003 à 20:52. (lien). Évalué à 0.Avec plaisir :
Pour le modem (winmodem comme souvent sur les portables) j'utilise un modules compilé a part, qui planté ma gentoo (freeze complet du system => reboot obligé :-( ) ou bout d'un temps aléatoire ... jamais rien eu de tel avec debian.-
[^]Re: Test de la Gentoo 1.4
Posté par Brice Arnould ( un_brice ) (page perso, ) le 13/09/2003 à 07:21. (lien). Évalué à 1.Je pense qu'il est possible de créer un gros hack tellement mal foutu (un module par exemple) qu'il planteras 9 fois sur 10, sauf avec le noyeau par défaut de Gentoo.
Est-ce que tu considereras que c'est une preuve de la stabilité de cette dernière ?
Pour autant que je me souvienne, Debian utilise un vanilla-kernel (+correction de sécurité) par défaut.
Alors essaie d'emerger "sys-kernel/vanilla-sources". C'est le noyau tout propre, et si il plante, Gentoo à rien à voir.--
Respect à RMS.
-
-
-
-
[^]Re: Test de la Gentoo 1.4
Posté par Jérôme () le 11/09/2003 à 19:04. (lien). Évalué à 3.Brah, allons à l'essentiel ... Le système de gestion des paquetages de Gentoo est pas top. Une preuve ? Essayez de désinstaller un paquetage et toutes les dépendances filles de ce paquetage (du genre, je vire GTK et ça vire tout seul les applis GTK), chez Gentoo, ya pas.
Ensuite, ya le terrible emerge -U world. Celui là provoque assez souvent (surtout quand l'install se fait vieille) des petits problèmes genre segfaults à ramasser à la pelle, surtout sur les applis GTK.
Il en reste que c'est quand même sympa, mais le Portage *est* moins bon que APT et les emerge world *est* moisn bon que apt-get distupgrade (qui installe une sid a partir d'autre chose que d'une woody ?)
Dernier truc entre Gentoo et Debian, l'éthique. Je crois que c'est bien la chose qui m'a fait lacher Gentoo pour Debian (retour aux sources). Franchement, chez Gentoo, ils sont pas très clairs sur le financement à partir de produits proprio (jeux, VMware, ...)
-
-
-
Faites gaffe aux captures d'écran !
Dis, dwight, t'en fais quoi de tes 18 sessions en cours sur linuxfr.org ?
-
[^]Re: Faites gaffe aux captures d'écran !
Posté par FRLinux (page perso, ) le 10/09/2003 à 11:43. (lien). Évalué à 0.Oh tu charies, il m'en reste 4 la ...
Steph
Le compilo?
Bon, je sais que je vais me faire fouter, mais bon, une question me turlupine depuis quelques temps. J'ai eu a constaté que les compilateur d'Intel était trés puissant. Les gains en temps de calculs aprés une simple recompilation pouvant aller de 10% à 50% sur les compilateurs courants.
Même si le compilo d'Intel est payant et pas libre, je me demande quel serait le gain en performance sur une ditribution de type Gentoo.
Quelqu'un a-t'il déjà fait un tel test (avec une version d'evaluation)?
Je sais que ma question risque d'énerver certaines personnes, mais bon, ca pourrait être interressant de savoir.
-
[^]Re: Le compilo?
-
[^]Re: Le compilo?
-
[^]Re: Le compilo?
Posté par SMKaribou (page perso, ) le 11/09/2003 à 08:27. (lien). Évalué à 0.Le compilo Intel est gratuit pour les particuliers (package icc dans gentoo :) ).
Et il compile surtout beaucoup plus vite que gcc pour du c++. Paske gcc c'est une bonne brouette de ce coté la.
-
[^]Re: Le compilo?
Posté par Philippe Fremy (page perso, ) le 11/09/2003 à 09:41. (lien). Évalué à 1.J'ai vu qq'un dans les forum de gentoo porter gentoo pour icc. Je ne me rappelle pas si il a vu un gain de performance net mais en tout cas, ca a deja ete fait.
-
[^]Re: Le compilo?
Posté par FRLinux (page perso, ) le 11/09/2003 à 18:35. (lien). Évalué à 1.Y'a un test paru sur le linux journal, en Anglais dans le texte mais sympa :
http://www.linuxjournal.com/article.php?sid=6766(...)
Steph
Re: Test de la Gentoo 1.4
" La question que tout le monde se pose s'est : qu'est ce qui est le plus rapide entre l'installation GRP et celle toute compilée ? Eh bien c'est grosso modo la même chose. Cerise sur le gateau, j'ai ensuite installé prelink qui est un programme se chargeant de créer un cache pour les librairies afin d'accélerer le chargement des applications de votre système. Il faut savoir que Mandrake par exemple est compilée avec support prelink."
Mandrake ne founit pas ces binaires avec prelink activé, c'est pour la prochaine fournée (cf. http://linuxfr.org/comments/254763.html(...) par un dev de Cooker)
A+
Laurent
-
[^]Re: Test de la Gentoo 1.4
Posté par Austin () le 11/09/2003 à 22:49. (lien). Évalué à 1.Prelink sera dans la prochaine Redhat (Oct 2003).
Pour avoir testé, ça ne change pas grand chose. Du moins pour les programmes en C.-
[^]Re: Test de la Gentoo 1.4
Posté par Olivier Jeannet () le 12/09/2003 à 09:21. (lien). Évalué à 2.Prelink sera dans la prochaine Redhat (Oct 2003).
Pour avoir testé, ça ne change pas grand chose. Du moins pour les programmes en C.
Evidemment, puisque le prelink (appelé initialement "obj-prelink") concerne le C++ !
L'édition de liens en C++ pose tout un tas de problèmes (il y a des articles intéressants à ce sujet, qui ont déjà été mentionnés sur ce site, sinon recherche sur le site de KDE) nettement plus complexes que l'édition de liens en C, qui elle ne pose aucun problème.
-
Cette page a été générée par Templeet en 0.2671s (dont 0.0729 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.