Bonjour, je souhaiterais connaitre la derniere version de la red hat, et également savoir a quel endroit je peut trouver cette derniere à télécharger (en francais de préférence)
Au passage, entre la Red hat et la Mandrake 10.1 official
la quel me conseilleriez vous, et pourquoi, si ce n'est trop vous demander?
Merci Mile fois...
Forum Linux.redhat Débutant en mank d'information
4
nov.
2004
# Redhat is dead...
Posté par Adrien BUSTANY (site web personnel) . Évalué à 3.
-> http://www.fedora.redhat.com(...) (en anglais)
Quant au choix de la distrib (il s'agit ici d'y aller avec des pincettes), je pense que cela dépend de l'utilisation de ta machine. Est-ce un serveur, une station perso ?
[^] # Re: Redhat is dead...
Posté par Ph3nX . Évalué à 1.
Linux c'est essentielement pour dévelloper que je m'en sert, pour faire des site et pour le boulot.
Conclusion?.
Merci pour les info sur la red hat :D enfin Fedora...
[^] # Re: Redhat is dead...
Posté par Adrien BUSTANY (site web personnel) . Évalué à 3.
La Mandrake semble plus accessibles pour les débutants (j'en ai jamais eu), et propose une francisation de qualité, ainsi que des outils de configuration performants. Elle utilise comme environnement de bureau KDE (mais c'est pas obligatoire).
La Fedora est peut être parfois moins francisée (j'utilise une Fedora), et demande surement plus souvent d'avoir recours au terminal. Elle propose Gnome (pas obligatoire) comme environnement de bureau par défaut.
Il n'y a pas de logiciels spécifiques au distributions, et toutes les distribs à mon avis sont hautement personnalisables. Le mieux est surement de lire des avis utilisateurs, et de déterminer la distribution qui convient à ton profil. Il existe également d'autres choix que Mandrake ou Fedora.
Pourquoi j'utilise une Fedora ? (No troll)
- J'aime bien Gnome
- Redhat depuis toujours ;) (pas une raison)
- J'aime bien la façon dont sont organisés les fichiers de configuration, le produit est bien fini
# Red Hat, Fedora, Mandrake
Posté par 007 . Évalué à 2.
* Red Hat Enterprise Linux (RHEL):
http://www.redhat.com/software/rhel/(...)
C'est pour les entreprises et c'est "cher". Mais c'est du logiciel libre, les sources sont disponibles.
* Fedora Core (FC):
http://fedora.redhat.com/(...)
Distribution pour les "enthousiastes". Développement dirigé par Red Hat mais aussi plus ouvert. Les discutions sont publics, les contributions accèptées, etc...
Mais ce n'est pas aussi communautaire que Gentoo ou Debian.
Il y a un tableau qui résume les différences entre FC et RHEL ici :
http://fedora.redhat.com/about/rhel.html(...)
Il faut noter que ce ne sont pas deux distributions totalement séparées. La future RHEL sera basée sur FC3 (c'est pour ça qu'il y a beaucoup de développeurs Red Hat sur Fedora).
La description du projet est ici (lecture fortement recommendée) :
http://fedora.redhat.com/about/(...)
Fedora Core 3 doit sortir le 8 novembre. Si tu envisages d'utiliser Fedora, il est intéressant d'attendre quelques jours.
Intructions de download :
http://fedora.redhat.com/download/(...)
Les mirroirs :
http://fedora.redhat.com/download/mirrors.html(...)
Entre Fedora Core et Mandrake, c'est grosso-modo la même chose d'un point de vu utilisateur. Fedora est un poil plus à jours actuellement (c'est beaucoup fonction des dates de sortie des distributions).
Pour Fedora, il y a cette excellente Faq :
http://www.fedorafaq.org/(...)
Elle sera mise à jours pour FC3. La version française est ici :
http://perso.wanadoo.fr/fester/faq-fedora.html(...)
En fait, Mandrake a un avantage significatif en France. Il y a plus d'utilisateurs de Mandrake que d'utilisateur de Fedora en France. Tu trouveras plus facilement de l'aide avec Mandrake.
Fedora a un autre avantage, tout est gratuit. Il n'y a pas le pack+ réservé aux abonnés de ...
Je ne connais pas bien Mandrake, donc attends l'avis d'un "pro-Mandrake" avant de te faire un avis.
# Ha redhat
Posté par Pinaraf . Évalué à -1.
Pourquoi cet engouement pour ce format ? Perso je trouve dpkg meilleur (surtout conjoint à apt-get !)
[^] # Re: Ha redhat
Posté par 007 . Évalué à 1.
Comment tu vérifies un paquet installé avec dpkg ?
Avec rpm :
rpm -V {nom_paquet}
Si tu utilises prelink (qui modifie les binaires) ça marche aussi pour les binaires car rpm vérifie "intelligement" les binaires modifié par prelink.
Que fait dpkg ?
rpm fait beaucoup de détections automatique de dépendance. dpkg ne fait pas ça avec les fichiers .so. Désinstalles linux-atm, dpkg ne vera pas que ppp (pppoatm) en dépend.
rpm a les dépendances pour l'installation (PreRequire), l'utilisation (Require) et la désinstallation.
rpm a un système de "roll-back" (utilisé par up2date). Si une installation ou une mise à jours ne marche pas comme tu veux, tu peux revenir en arrière.
Dpkg a ça ?
rpm supporte i386 et amd64 en parallèle.
Dpkg ?
rpm supporte l'installation de paquet qui sont "moyennement" en conflit. C'est-à-dire que des paquets peuvent avoir les mêmes fichiers et les paquets seront autorisés à cohabité si les fichiers en commun sont identiques.
rpm supporte les paquets relogeable (rpm --prefix ...)
rpm supporte les dépendances inter-paquet (dans ce cas, il faut évidement faire des transactions avec plusieurs paquets à la foi (c'est pour ça qu'il y a yum/apt/up2date).
Bref, rpm est _très_ bien.
> surtout conjoint à apt-get !
Il y a apt-get pour rpm comme il y a apt-get pour dpkg...
[^] # Re: Ha redhat
Posté par Pinaraf . Évalué à -1.
Avantages de dpkg :
- sensiblement plus rapide
- dépendances plus nombreuses (dépendances conseillées, suggérées...)
Que fait dpkg ?
J'utilise pas prelink, peux pas savoir (d'ailleurs, il sert à quoi ? J'ai lu des trucs sur de l'optimisation, mais il fait quoi exactement ?)
rpm fait beaucoup de détections automatique de dépendance. dpkg ne fait pas ça avec les fichiers .so. Désinstalles linux-atm, dpkg ne vera pas que ppp (pppoatm) en dépend.
Heu oui et ?
Perso je considère que ton exemple montre un défaut du paquet ppp (pppoatm) plutôt qu'un défaut de dpkg
rpm supporte les paquets relogeable (rpm --prefix ...)
Chapeau, c'est vachement dur à coder (c'est à se cogner la tête contre les murs pour gérer les scripts post-install, j'aimerais savoir comment il gère ça)
Mais j'en ai jamais eu l'utilité...
rpm a un système de "roll-back" (utilisé par up2date). Si une installation ou une mise à jours ne marche pas comme tu veux, tu peux revenir en arrière.
GNI ? Sauvegarde de tous les paquets que tu mets à jour ????
rpm supporte i386 et amd64 en parallèle.
Heu, dpkg n'a pas à le supporter : tous les paquets sont dispos pour les deux à la fois ou presque...
rpm supporte les dépendances inter-paquet
Ho ! Comme dpkg quoi
[^] # Re: Ha redhat
Posté par 007 . Évalué à 0.
Ce qui n'a rien de difficile à gérer. C'est au développeur du paquet d'ajouter l'info, c'est aux programmes utilisateurs de lire l'info et de l'afficher. Bref, pour le gestionnaire de paquet il n'y a rien à faire (juste prévoir de la place pour stocker l'information).
> et l'utilisation de rpm est en chute libre...
Évidement, tu n'as aucun chiffre pour appuyer ça. T'as fait une remarque qu'on pouvait lire il y a plusieurs années. C'est dire si ce n'est pas pertinent pour un sou.
Pour ton info, car j'ai l'impression que c'est confus dans ta tête :
yum => utilise rpm
apt4rpm => utilise rpm
urpmi => utilise rpm
> - sensiblement plus rapide
Oui. Mais aussi car rpm est plus "subtil". Par exemple glibc-2.3.3 ne fornit pas que glibc 2.3.3. Mais :
GLIBC_2.0 (exemple : libnss_dns.so.1(GLIBC_2.0), libpthread.so.0(GLIBC_2.0))
GLIBC_2.1
GLIBC_2.1.1
GLIBC_2.1.2
GLIBC_2.1.3
GLIBC_2.2
GLIBC_2.2.1
GLIBC_2.2.2
GLIBC_2.2.3
GLIBC_2.2.4
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
Celà est détecté automatiquement. Si t'as un programme qui a besoin de GLIBC_2.0, pas de problèmes. Les Requires sont aussi fait automatiquement. Pas de risque d'oublier un "Requires glibc > 2.3.1".
> Perso je considère que ton exemple montre un défaut du paquet ppp (pppoatm) plutôt qu'un défaut de dpkg
Avec rpm, tu n'as rien à faire pour que ces dépences soient détectées. Avec dpkg, il faut le faire à la main. Peut-être pas un défaut de dpkg mais c'est une faiblesse par rapport à rpm (qui a ça depuis.... fort fort longtemps).
> Heu, dpkg n'a pas à le supporter : tous les paquets sont dispos pour les deux à la fois ou presque...
N'as pas à le supporté car Debian ne propose pas de distribution amd64 qui permet d'avoir des programmes i386. Actuellement il n'y a pas openoffice pour amd64 par exemple.
Ben avec rpm, tu as un système amd64 + openoffice en i386 (car ça n'existe pas en amd64) avec ces dépendance en i386. A côté de ça, tu as aussi les lib amd64 pour les programmes en amd64.
T'es content d'un système qui ne gère pas prelink, qui ne gère pas automatiquement les versions d'api, qui ne fait pas de détection require/provide automatique, ne propose pas de distribution amd64, etc...
Mieux, tu trouves ça bien...
Apparament, t'y comprend rien en gestionnaire de paquets.
[^] # Re: Ha redhat
Posté par Pinaraf . Évalué à 1.
> Évidement, tu n'as aucun chiffre pour appuyer ça.
Tu m'as pas compris ! Je n'utilise plus dpkg, et j'utiliserai à l'avenir de moins en moins rpm...
Évidemment, en prenant ça pour une généralité...
c'est confus dans ta tête
Pas du tout...
Perso, mon point de vue concernant les dépendances : c'est pas à rpm de les gérer (ni à dpkg) dans le cas de glibc que tu as donné, mais plus à rpm-builder ou autre créateur de packages de calculer TOUTES les dépendances automatiquement à grands coups de ldd...
distribution amd64 qui permet d'avoir des programmes i386.
Ha tu voulais dire ça...
Remarque : il n'y a pas d'openoffice2 hormis sous forme de rpm actuellement...
Apparament, t'y comprend rien en gestionnaire de paquets.
C'est surtout que j'ai jamais cherché les subtilités de rpm et dpkg, je dis juste mon avis, et tu as mal interprété certaines de mes phrases tout comme j'ai sûrement mal interprété certaines des tiennes.
[^] # Re: Ha redhat
Posté par 007 . Évalué à 0.
Tu as dit :
- Perso j'utilise plus dpkg, et l'utilisation de rpm est en chute libre...
Alors que tu voulais dire :
- Perso j'utilise plus dpkg, et mon utilisation de rpm est en chute libre...
Désolé d'avoir fait attention à ce que tu écris.
[^] # Re: Ha redhat
Posté par 007 . Évalué à 0.
Reconstruction à la volée du paquet installé (avec les modifications des fichiers de configuration).
M'enfin, c'est la millième foi que je vois rpm critiqué sans une seule critique valable (sauf les paquets suggérés/recommendés). T'as aussi oublié de parler de debconf. Mais debconf est plus lié à la philosophie de la distribution qu'au gestionnaire de paquet. Par exemple Ubuntu fait peu usage de Debconf.
On peut s'interroger sur le succès de dpkg. dpkg est souvent utilisé par des distributions _basée_ sur Debian pour profiter des paquets Debian et pas forcément pour dpkg. Ainsi avec Ubuntu/Progeny/etc tu peux profiter des paquets de Debian.
rpm est utilisé pour rpm. Mandrake ou SuSE n'utilisent pas les paquets de Red Hat. Ce n'est pas un défaut de rpm, c'est le choix des distributeurs de ne pas être chercher a être compatible (ça ajouterais une dépendance "lourde" à gérer). Il y a Aurox qui est compatible Fedora, plus tous les dérivés de RHEL qui sont compatible RHEL. Je dis ça, uniquement pour dire que c'est aussi possible avec rpm.
S'il y a des distributions basées sur Debian, ce n'est pas grace à dpkg mais grace à Debian. Faut pas tout mélanger.
[^] # Re: Ha redhat
Posté par 007 . Évalué à 0.
C'et aussi le format "standard" pour LSB.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.