Aller plus loin
- Article (7 clics)
Test de la Gentoo 1.4
10
sept.
2003
La Gentoo 1.4 est sortie début août avec le retard qu'on lui connaît, cela valait-il la peine d'attendre ? Eh bien c'est la question à laquelle je tente de répondre par ce test contenant peu de captures cette fois ci (car ce n'est pas son objectif) mais permettant de voir de plus près à quoi ressemble une Gentoo et son mystère concernant le terme de distro source. J'ai également comparé la partie GRP (Gentoo Release Platform) qui vous permet d'installer une Gentoo pré-compilée taillée pour votre processeur.
# Re: Test de la Gentoo 1.4
Posté par Guillaume CASTAGNINO (site web personnel) . Évalué à 6.
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 . Évalué à -2.
[^] # Re: Test de la Gentoo 1.4
Posté par Frederick Ros . Évalué à 5.
[^] # Re: Test de la Gentoo 1.4
Posté par Xavier Poinsard . Évalué à 2.
[^] # Re: Test de la Gentoo 1.4
Posté par nooky59 . Évalué à -6.
[^] # Re: Test de la Gentoo 1.4
Posté par Arachne . Évalué à 5.
[^] # Re: Test de la Gentoo 1.4
Posté par nooky59 . Évalué à -2.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 4.
[^] # Re: Test de la Gentoo 1.4
Posté par Guillaume CASTAGNINO (site web personnel) . Évalué à 2.
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 . Évalué à 1.
[^] # Re: Test de la Gentoo 1.4
Posté par a_jr . Évalué à -3.
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 drac . Évalué à -4.
Enfin personnellement j'ai pas été convaincu par Gentoo, j'ai toujours eu l'impression d'avoir les désavantages de Linux et des *BSD réunis.
[^] # Re: Test de la Gentoo 1.4
Posté par pyrollo (site web personnel) . Évalué à 0.
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 . Évalué à 0.
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 un_brice (site web personnel) . Évalué à 4.
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.
[^] # Re: Test de la Gentoo 1.4
Posté par a_jr . Évalué à 2.
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 . Évalué à 1.
> 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 . Évalué à 3.
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 . Évalué à 0.
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 . Évalué à 2.
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 . Évalué à 0.
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 5.
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 . Évalué à -3.
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 . Évalué à 3.
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 . Évalué à -1.
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 . Évalué à 1.
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 . Évalué à 2.
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
Posté par nooky59 . Évalué à 0.
# Re: Test de la Gentoo 1.4
Posté par Midilaïr (site web personnel) . Évalué à 3.
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 . Évalué à 3.
http://www.gentoo.org/main/en/mirrors.xml(...)
[^] # Re: Test de la Gentoo 1.4
Posté par FRLinux (site web personnel) . Évalué à 1.
Steph
[^] # Re: Test de la Gentoo 1.4
Posté par passant·e . Évalué à 4.
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 ->[]
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Test de la Gentoo 1.4
Posté par madko (site web personnel) . Évalué à 1.
[^] # Re: Test de la Gentoo 1.4
Posté par Erwan . Évalué à 3.
# Noyau SMP
Posté par Gentoo][Gravis . Évalué à 3.
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 . Évalué à 3.
[^] # Re: Noyau SMP
Posté par FRLinux (site web personnel) . Évalué à 2.
Steph
[^] # Re: Noyau SMP
Posté par drac . Évalué à 1.
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 . Évalué à 4.
[^] # Re: Noyau SMP
Posté par drac . Évalué à 1.
[^] # Re: Noyau SMP
Posté par Gentoo][Gravis . Évalué à 1.
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
Posté par RB . Évalué à 9.
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 . Évalué à 1.
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 . Évalué à 3.
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 iznogoud . Évalué à 1.
[^] # Re: Test de la Gentoo 1.4
Posté par RB . Évalué à 1.
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 rootix . Évalué à 1.
[^] # Re: Test de la Gentoo 1.4
Posté par Gentoo][Gravis . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 2.
Ç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 un_brice (site web personnel) . Évalué à 2.
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).
[^] # Re: Test de la Gentoo 1.4
Posté par jerome bagattin . Évalué à 0.
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 un_brice (site web personnel) . Évalué à 1.
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.
[^] # Re: Test de la Gentoo 1.4
Posté par jerome (site web personnel) . Évalué à 3.
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 !
Posté par Xmanu . Évalué à 0.
[^] # Re: Faites gaffe aux captures d'écran !
Posté par FRLinux (site web personnel) . Évalué à 0.
Steph
# Le compilo?
Posté par walloo . Évalué à 4.
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?
Posté par Austin . Évalué à 2.
Le compilo d'intel a un avantage pour les calculs, en fait pour certain calcul.
Si tu projetes de transformer ta gentoo en noeud de calcul pour un cluster c'est peut-être intéressant.
[^] # Re: Le compilo?
Posté par Xmanu . Évalué à 1.
[^] # Re: Le compilo?
Posté par SMKaribou . Évalué à 0.
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 F (site web personnel) . Évalué à 1.
[^] # Re: Le compilo?
Posté par FRLinux (site web personnel) . Évalué à 1.
http://www.linuxjournal.com/article.php?sid=6766(...)
Steph
# Re: Test de la Gentoo 1.4
Posté par Laurent Saint-Michel . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 2.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.