> Dans le cas de urpmi et mandrake ce n est pas geré comme cela , tous les paquets OO.org-l10n- "provident" la meme chose ( a savoir OO.org-l10n ) et le paquet OO.org "require" OO.org-l10n donc urpmi voyant que plusieurs paquets provides la meme chose , il donne le choix et donc forcement les langues :)
C'est une bonne solution mais qui fait une peu "bidouillage".
Comment se passe les mise à jours de la version 1.1 à 1.2 par exemple ? De nouveau des questions ? Comment faire des mises en batch sans perdre de langues ?
On tombe sur une réelle limitation de rpm. urpmi fait ce qu'il peut avec ce qui est disponible.
Sous Fedora pour kde on a :
kde-i18n-Finnish-3.2.2-2.noarch.rpm
kde-i18n-Korean-3.2.2-2.noarch.rpm
kde-i18n-Slovak-3.2.2-2.noarch.rpm
Avantage : on peut installer plusieurs langs, pas de problème de mise à jour.
Inconvénient : kde-i18n-* n'est jamais installé automatiquement.
> Pour le tag %lang c est géré par une macro
Pour cette partie, j'ai dit quelques conneries... Pas pris le temps de vérifier.
> ( %find_lang )lors de la construction de ton paquet et si tu met tout dans le meme paquet , rpm n installera que la langue definie dans /etc/rpm/macros
Macro _install_langs ici.
/usr/lib/rpm/macros # A colon separated list of desired locales to be installed;
# "all" means install all locale specific files.
#
%_install_langs all
Par contre il y a toujours le problème pour ajouter une langue à un système déjà installé.
Le mieux est de tester avec la branche développement.
Souvent le noyau Arjan van de Ven est le même que la branche de développement. Mais parfois c'est un truc très spécifique qu'il est sage d'éviter (genre "connu pour manger vos enfants").
Pour ton problème regarde si tu peux contourner internet-druid en remplissant toi même les fichiers dans /etc/sysconfig.
La doc est ici :
/usr/share/doc/initscripts-*/sysconfig.txt
> urpmi OpenOffice.org et il me propose de choisir quel package de langue installer :)
+1
> Bon, donc c'est la faute de apt et de yum :)
C'est rpm qui ne le supporte pas . En réalité c'est supporté par rpm. C'est tag lang. Lorsque tu installes un paquet il ne mets que les langues définit dans /etc/sysconfig/i18n.
Mais ça pose d'autres problèmes.
Entre autre, comment ajouter d'autres langues à un système déjà installé sans faire des ugly : rpm -i bidule-i18n-lang machin-i18n-lang ....
> ce gros rc.sysinit
Sous FC2 :
$ wc /etc/rc.d/rc.sysinit
857 /etc/rc.d/rc.sysinit
Je doit bien avouer que ce "problème" est le cadet de mes soucis.
> qui n'en fini par de grossir
Non. Lorsque c'est possible, des éléments sont déplacés dans /etc/rc.d/init.d/ . C'est aussi pour ça que rc.sysinit est si petit.
Normalement il n'y a pas de raison de virer des trucs de rc.sysinit. Sauf pour améliorer la durée du boot dans une magnitude non significative.
Pour ajouter des trucs, c'est rc.local qu'il faut utiliser ou /etc/rc.d/init.d/ .
L'avantage, c'est que quand tu fais :
yum install openoffice.org
yum installe aussi openoffice.org-i18n car il y a une dépendance.
Si le paquet est splité ce n'est pas possible (ou pas supporté actuellement).
Il y a ce problème avec k3b sous FC2 :
yum install k3b
et le bon kde-i18n-... n'est pas installé. C'est un problème classique des utilisateurs de k3b sous Gnome qui n'ont pas installé KDE à l'installation.
> Alors que Mandrake et dans une moindre mesure Suse ont compris que ce genre de packaging etait pourri
Il est pas pourri. Il a ses défauts et ses avantages. Son seul défaut, c'est la place disque. Le split a d'autres défauts.
> Si les gens qui participent au projet pouvaient soumettre cette idée sur la ml des devels, ca serait pas un luxe :)
Déjà discuté. Pas de bonne solution actuellement.
L'autre problème, est comment faire s'imple lorsqu'on ajoute une langue. Par exemple un allemand utilise ta bécane et du veut installer l'allemand. Si les paquets sont splités il n'y a pas de solution simple actuellement. Avec la "méthode" RedHat la langue est déjà là.
> Au passage, si vous pouviez aussi leur dire de dégager l'horrible rc.sysinit et de passer à un système de boot plus modulaire(comme debian et suse)
????
SuSE et Debian on forcément un équivalent de rc.sysinit.
Ou alors ils sont très très fort.
Je t'invites à lire le contenu du fichier :
/etc/rc.d/rc.sysinit
Car je sais vraiment pas où tu veux en venir.
Puis il me semble que Debian utilise grosso-modo la même méthode de boot que Fedora.
Si tu as pris ce journal au sérieu, c'est très très très grave.
De plus il n'est pas très sérieux de vérifier une news en ne regardant que les journaux de l'auteur de la news. C'est pas du boulot...
Sinon 2.6.5 ou 2.6.6-rc3.... je m'en fous un peu. Le coeur de "débat" n'était pas là. Il était sur les justifications du retard de la news et *surtout* sur les non corrections de news bidonnées soit disant vérifiées recoupées, etc...
Je vois que le news a été corrigée (le 2.6.5 ou 2.6.6-rc3-bk3 est un détail pour moi). C'est bien mais c'est trop tard.
Je répète : l'erreur est humaine.
Mais :
1° Corriger les news (toutes les news, même les news RedHat).
2° et vite (c-à-d pas à plus de 36 heures de la sortie de la news).
Récupération du CVS.
# cd eagleusb
copy du .spec pour construire le paquet
# cp eagle-usb.spec ~/rpmbuild/SPECS/
tu peux utiliser /usr/src/redhat/SPECS si tu utilises le compte root.
copy avec le "bon" nom du répertoire.
# find . -depth -print0 | cpio -pv --null -a -m -d ../eagle-usb-1.9.7
creation du tarball pour faire le rpm.
# cd ..
# tar cvfj rpmbuild/SOURCES/eagle-usb-1.9.7.tar.bz2 eagle-usb-1.9.7/
( /usr/src/redhat/SOURCES/eagle-usb-1.9.7.tar.bz2 avec le compte root).
Création du rpm
# cd ~/rpmbuid/SPECS
# rpmbuid -ba --define "kernel 2.6.5-1.358" eagle-usb.spec
J'ajoute "--define "kernel 2.6.5-1.358"" car je suis pas exactement sous le noyau standard. Ce n'est pas nécessaire normalement.
Il me reste des warnings : warning: kernel-sources version is different from the current kernel.
C'est normal. Expliqué plus haut je peux le corrigé.
warning: dhclient or dhcpcd where not found. Unless your ISP is 'Free D�group�',
it is not a problem.
C'est normal, il faut que je refasse le paquet après avoir installé dhcp.
warning: since pppoe was not found on your disk, pppoe support has been disabled.
Normal, il faut que je refasse le paquet après avoir installé pppoe.
Donc normalement il n'y a pas de problème ici.
Si tu n'y arrives pas, dis le moi et je mets les paquets en ligne.
C'est rigolo mais les noyaux dans boot.iso, diskboot.img, dans les répertoires images/pxeboot/ et isolinux sont tous les même :-)
Maintenant que RedHat ne se prend pas la tête avec la taille pour que ça rentre dans une disquette, ce n'est pas un problème.
> extraire le noyau de l'image? Il faut la monter?
# mkdir tmp
# mount -o loop,ro diskboot.img tmp
[....]
# umount tmp
# rmdir tmp
> root= ????
Sans importance. À virer.
> append="????"
append="initrd=initrd.img ramdisk_size=8192 askmethod"
Je ne suis pas sûr si "initrd=initrd.img" est nécessaire. J'ai pas utilisé lilo depuis que j'ai arrêté de sucer mon pouce :-)
Exemples : http://fedora.redhat.com/about/index.html(...) we hope to provide an operating system more in line with the ideals of free software and more appealing to the open source community.
Je vois pas "desktop user".
Fedora Core is intended to be a logical upgrade path for previous users of Red Hat Linux whose needs are consistent with the objectives of the Fedora Project.
The community is defined as those who not only consume but also produce for the good of other community members. Community users may:
* Participate in development of open source software
* Report bugs
* Test software
* Advocate Open Source, Linux
* Participate in mailing lists
* Experiment with the technology
* Help others in the community
* Educate students
Nul part je vois desktop. Prétendre faire un desktop sans support, sans flash, sans java, sans mp3, sans video, etc... est du suicide.
Ce qui n'empêche pas FC2 d'être sympathique en desktop quand on est "un peu malin" :-)
S'il y a une qualité qu'il faut reconnaitre à RedHat, c'est la transparence de la description du projet. Pas de langue de bois. Pas de promesses intenables.
Une doc de très grande qualité même si pas à jours. Néanmoins, il a raison. La doc devrait aussi être livrée. Mais la communauté n'est pas très chaude pour faire de la doc... Pas grave, il y aura toujours la doc RHEL.
Bugs - The Ugly
Lack of basic multimedia support
Voir le "cahier des charges" de Fedora Core.
C'est comme si il reprochait à GNU/Linux de ne pas être proprio...
Verdict - The Editor's Opinion
A nice system, but I can find no reason to use it instead of other distributions
Quelle bêtise. C'est typique des testeurs. Il font un test durant 3 heures dont 20 minutes pour configurer yum. Forcément, ils ne retiennent que ça. Yum je le configure à chaque fois que je monte en version : tous les 6 mois. 20 minutes tout les 6 mois pour avoir mplayer, mpg32, c'est claire que je m'en fous complètement.
Es-ce qu'un jours les gens sauront que Fedora ne s'attaque pas au marché du desktop ?
C'est pourtant pas compliqué, c'est expliqué sur le site web de Fedora.
> La méthode ci-dessous sert à avoir la même rapidité de Mandrake ou voir plus.
Heu nptl pour Mandrake c'est à partir de Mandrake 10.0. Nptl a été fourni en premier par Red Hat (RH9). Normal, ils l'ont développé.
> J'ai l'impression que le système est un peu plus réactif.
> Quand pensez-vous ?
C'est psychologique alors.
nptl c'est bien :
- pour les développeurs
- pour les serveurs avec plein de thread (apache 2, serveur java...).
C'est l'interface linuxthread qui est utilisé par défaut. FC3 utilisera l'interface nptl par défaut. Donc plus rien à faire pour avoir nptl. Conséquence : incompatible i386. Il faut passer à i486 (c'est en cours de discution sur la mailing devel).
[^] # Re: raccourci mozilla
Posté par 007 . En réponse au journal Fedora Extra. Évalué à 1.
Merci.
[^] # Re: raccourci mozilla
Posté par 007 . En réponse au journal Fedora Extra. Évalué à 1.
# La paternité de Linux discutée
Posté par 007 . En réponse à la dépêche La paternité de Linux discutée. Évalué à 10.
[^] # 74F4Z("LT1C1:*"1-23I674\H,$A@8`H` `
Posté par 007 . En réponse au journal Fedora Extra. Évalué à -5.
E(&QE<R!D:7-T<FEB=71I;VYS('!E=79E;G0@;&4@9F%I<F4N"@``
`
[^] # +4F4Z($MI:V]O(0H` `
Posté par 007 . En réponse au journal Fedora Extra. Évalué à -4.
M)V5S="!P87,@=')O<"!T92!D96UA;F1E<C\*"DYO;BP@8R=E<W0@=')O<"!M
M92!D96UA;F1E<BX*"DUA:7,@96X@8VAE<F-H86YT('5N('!E=2!D=2!V82!T
H<F]U=F5R(&QE(&-O9&%G92!T<FEV:6%L('%U92!J)W5T:6QI<V4N"@``
`
[^] # Re: Kikoo!
Posté par 007 . En réponse au journal Fedora Extra. Évalué à -5.
%;VER+@H`
`
# La pô fait exprès
Posté par 007 . En réponse au journal Fedora Extra. Évalué à -10.
Cliquer sur inutile pour participer à mon acte de contrition.
Merci, ça fait du bien.
[^] # Re: Packaging sous RedHat/Fedora
Posté par 007 . En réponse au journal Packaging sous RedHat/Fedora. Évalué à 1.
C'est une bonne solution mais qui fait une peu "bidouillage".
Comment se passe les mise à jours de la version 1.1 à 1.2 par exemple ? De nouveau des questions ? Comment faire des mises en batch sans perdre de langues ?
On tombe sur une réelle limitation de rpm. urpmi fait ce qu'il peut avec ce qui est disponible.
Sous Fedora pour kde on a :
kde-i18n-Finnish-3.2.2-2.noarch.rpm
kde-i18n-Korean-3.2.2-2.noarch.rpm
kde-i18n-Slovak-3.2.2-2.noarch.rpm
$ rpm -q --provides -p kde-i18n-Slovak-3.2.2-2.noarch.rpm
kde-i18n-Slovak = 1:3.2.2-2
Avantage : on peut installer plusieurs langs, pas de problème de mise à jour.
Inconvénient : kde-i18n-* n'est jamais installé automatiquement.
> Pour le tag %lang c est géré par une macro
Pour cette partie, j'ai dit quelques conneries... Pas pris le temps de vérifier.
> ( %find_lang )lors de la construction de ton paquet et si tu met tout dans le meme paquet , rpm n installera que la langue definie dans /etc/rpm/macros
Macro _install_langs ici.
/usr/lib/rpm/macros
# A colon separated list of desired locales to be installed;
# "all" means install all locale specific files.
#
%_install_langs all
Par contre il y a toujours le problème pour ajouter une langue à un système déjà installé.
[^] # Re: Confirmation d'un bug
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 2.
Le mieux est de tester avec la branche développement.
Souvent le noyau Arjan van de Ven est le même que la branche de développement. Mais parfois c'est un truc très spécifique qu'il est sage d'éviter (genre "connu pour manger vos enfants").
La branche de développement est ici :
http://download.fedora.redhat.com/pub/fedora/linux/core/development(...)
Il y a plein de miroirs.
J'utilise celui la :
http://fr2.rpmfind.net/linux/fedora/core/development/(...)
Pour ton problème regarde si tu peux contourner internet-druid en remplissant toi même les fichiers dans /etc/sysconfig.
La doc est ici :
/usr/share/doc/initscripts-*/sysconfig.txt
[^] # Re: Packaging sous RedHat/Fedora
Posté par 007 . En réponse au journal Packaging sous RedHat/Fedora. Évalué à 1.
+1
> Bon, donc c'est la faute de apt et de yum :)
C'est rpm qui ne le supporte pas . En réalité c'est supporté par rpm. C'est tag lang. Lorsque tu installes un paquet il ne mets que les langues définit dans /etc/sysconfig/i18n.
Mais ça pose d'autres problèmes.
Entre autre, comment ajouter d'autres langues à un système déjà installé sans faire des ugly : rpm -i bidule-i18n-lang machin-i18n-lang ....
> ce gros rc.sysinit
Sous FC2 :
$ wc /etc/rc.d/rc.sysinit
857 /etc/rc.d/rc.sysinit
Je doit bien avouer que ce "problème" est le cadet de mes soucis.
> qui n'en fini par de grossir
Non. Lorsque c'est possible, des éléments sont déplacés dans /etc/rc.d/init.d/ . C'est aussi pour ça que rc.sysinit est si petit.
Normalement il n'y a pas de raison de virer des trucs de rc.sysinit. Sauf pour améliorer la durée du boot dans une magnitude non significative.
Pour ajouter des trucs, c'est rc.local qu'il faut utiliser ou /etc/rc.d/init.d/ .
[^] # Re: Linux 2.6.5 ou Linux 2.6.6
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 0.
Le journal date du 16/05/2004 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
La distribution est sortie le 18/05 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
De plus le journal indique à la fin :
Je conseille d'attendre le 18. Au moins pour avoir la release note
C'est pas voilà ici. On n'a pas à faire les poubelles.
Je trouve délirant que vous justifié vos erreurs de vérification de news en vous appuyant sur des journaux FAIT PAR L'AUTEUR DE LA NEWS !
Pour recouper une info, il faut plusieurs sources et aussi aller à l'origine de la source :
kernel....src.rpm
C'est franchement n'importe quoi vos vérifications de news.
# Packaging sous RedHat/Fedora
Posté par 007 . En réponse au journal Packaging sous RedHat/Fedora. Évalué à 1.
L'avantage, c'est que quand tu fais :
yum install openoffice.org
yum installe aussi openoffice.org-i18n car il y a une dépendance.
Si le paquet est splité ce n'est pas possible (ou pas supporté actuellement).
Il y a ce problème avec k3b sous FC2 :
yum install k3b
et le bon kde-i18n-... n'est pas installé. C'est un problème classique des utilisateurs de k3b sous Gnome qui n'ont pas installé KDE à l'installation.
> Alors que Mandrake et dans une moindre mesure Suse ont compris que ce genre de packaging etait pourri
Il est pas pourri. Il a ses défauts et ses avantages. Son seul défaut, c'est la place disque. Le split a d'autres défauts.
> Si les gens qui participent au projet pouvaient soumettre cette idée sur la ml des devels, ca serait pas un luxe :)
Déjà discuté. Pas de bonne solution actuellement.
L'autre problème, est comment faire s'imple lorsqu'on ajoute une langue. Par exemple un allemand utilise ta bécane et du veut installer l'allemand. Si les paquets sont splités il n'y a pas de solution simple actuellement. Avec la "méthode" RedHat la langue est déjà là.
> Au passage, si vous pouviez aussi leur dire de dégager l'horrible rc.sysinit et de passer à un système de boot plus modulaire(comme debian et suse)
????
SuSE et Debian on forcément un équivalent de rc.sysinit.
Ou alors ils sont très très fort.
Je t'invites à lire le contenu du fichier :
/etc/rc.d/rc.sysinit
Car je sais vraiment pas où tu veux en venir.
Puis il me semble que Debian utilise grosso-modo la même méthode de boot que Fedora.
[^] # Re: Linux 2.6.5 ou Linux 2.6.6
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 0.
Quel journal ?
Je tiens a préciser que le journal avec la ligne :
- Linux 2.6.5
est un énorme troll ( http://linuxfr.org/~ehoebadoag/12903.html(...) ).
Si tu as pris ce journal au sérieu, c'est très très très grave.
De plus il n'est pas très sérieux de vérifier une news en ne regardant que les journaux de l'auteur de la news. C'est pas du boulot...
Sinon 2.6.5 ou 2.6.6-rc3.... je m'en fous un peu. Le coeur de "débat" n'était pas là. Il était sur les justifications du retard de la news et *surtout* sur les non corrections de news bidonnées soit disant vérifiées recoupées, etc...
Je vois que le news a été corrigée (le 2.6.5 ou 2.6.6-rc3-bk3 est un détail pour moi). C'est bien mais c'est trop tard.
Je répète : l'erreur est humaine.
Mais :
1° Corriger les news (toutes les news, même les news RedHat).
2° et vite (c-à-d pas à plus de 36 heures de la sortie de la news).
La qualité de dlfp ne peut qui gagner.
[^] # Re: Fedora News Updates #12
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 1.
http://www.bytebot.net/geekdocs/ibook/fedorappc.html(...)
Ça parait tout simple à faire. Impressionnant.
[^] # Re: Confirmation d'un bug
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 1.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123391(...)
Le bug est marqué "CLOSED RAWHIDE". Donc essaie le 2.6.6-1-374 de la branche développement :
http://fr2.rpmfind.net/linux/fedora/core/development/i386/Fedora/RP(...)
Si ça marche, ferme ton rapport de bug avec "CLOSED RAWHIDE".
Une mise à jours sera peut-être dispo avec Token Ring selon un mail dans mon archive.
En attendant indique que ton bug est peut-être lié au bug que je viens de t'indiquer.
[^] # Re: mon avis
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 1.
# yum install rpm-build
[^] # Re: mon avis
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 2.
Récupération du CVS.
# cd eagleusb
copy du .spec pour construire le paquet
# cp eagle-usb.spec ~/rpmbuild/SPECS/
tu peux utiliser /usr/src/redhat/SPECS si tu utilises le compte root.
copy avec le "bon" nom du répertoire.
# find . -depth -print0 | cpio -pv --null -a -m -d ../eagle-usb-1.9.7
creation du tarball pour faire le rpm.
# cd ..
# tar cvfj rpmbuild/SOURCES/eagle-usb-1.9.7.tar.bz2 eagle-usb-1.9.7/
( /usr/src/redhat/SOURCES/eagle-usb-1.9.7.tar.bz2 avec le compte root).
Création du rpm
# cd ~/rpmbuid/SPECS
# rpmbuid -ba --define "kernel 2.6.5-1.358" eagle-usb.spec
J'ajoute "--define "kernel 2.6.5-1.358"" car je suis pas exactement sous le noyau standard. Ce n'est pas nécessaire normalement.
Il me reste des warnings :
warning: kernel-sources version is different from the current kernel.
C'est normal. Expliqué plus haut je peux le corrigé.
warning: dhclient or dhcpcd where not found. Unless your ISP is 'Free D�group�',
it is not a problem.
C'est normal, il faut que je refasse le paquet après avoir installé dhcp.
warning: since pppoe was not found on your disk, pppoe support has been disabled.
Normal, il faut que je refasse le paquet après avoir installé pppoe.
Donc normalement il n'y a pas de problème ici.
Si tu n'y arrives pas, dis le moi et je mets les paquets en ligne.
[^] # Re: Installation réseau?
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 1.
Maintenant que RedHat ne se prend pas la tête avec la taille pour que ça rentre dans une disquette, ce n'est pas un problème.
[^] # Re: Installation réseau?
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 3.
# mkdir tmp
# mount -o loop,ro diskboot.img tmp
[....]
# umount tmp
# rmdir tmp
> root= ????
Sans importance. À virer.
> append="????"
append="initrd=initrd.img ramdisk_size=8192 askmethod"
Je ne suis pas sûr si "initrd=initrd.img" est nécessaire. J'ai pas utilisé lilo depuis que j'ai arrêté de sucer mon pouce :-)
> vga=788
À virer.
[^] # Re: mon avis
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 0.
[^] # Re: Test FC2
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 2.
Il faut lire toute la section http://fedora.redhat.com/about/(...) .
Exemples :
http://fedora.redhat.com/about/index.html(...)
we hope to provide an operating system more in line with the ideals of free software and more appealing to the open source community.
Je vois pas "desktop user".
Fedora Core is intended to be a logical upgrade path for previous users of Red Hat Linux whose needs are consistent with the objectives of the Fedora Project.
C'est aussi pour les anciens utilisateurs de RHL qui partagent les objectif de Fedora (qui ne sont pas les même que RHL). Voir ici pour les objectifs : http://fedora.redhat.com/about/objectives.html(...)
The community is defined as those who not only consume but also produce for the good of other community members. Community users may:
* Participate in development of open source software
* Report bugs
* Test software
* Advocate Open Source, Linux
* Participate in mailing lists
* Experiment with the technology
* Help others in the community
* Educate students
http://fedora.redhat.com/about/rhel.html(...)
Users Early adopters, enthusiasts, developers
Nul part je vois desktop. Prétendre faire un desktop sans support, sans flash, sans java, sans mp3, sans video, etc... est du suicide.
Ce qui n'empêche pas FC2 d'être sympathique en desktop quand on est "un peu malin" :-)
S'il y a une qualité qu'il faut reconnaitre à RedHat, c'est la transparence de la description du projet. Pas de langue de bois. Pas de promesses intenables.
[^] # Re: Test FC2
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 2.
Cons - The Bad
Default package management is lacking, limited documentation
Mouaiff. Fedora Core fournit Yum. Reproche-t-on à Debian de fournir apt-get ou à Gentoo de fournir emerge ?
Pour la documentation, il y a RH9 ou RHEL 3 :
http://europe.redhat.com/documentation/(...)
https://www.redhat.com/docs/manuals/enterprise/(...)
Une doc de très grande qualité même si pas à jours. Néanmoins, il a raison. La doc devrait aussi être livrée. Mais la communauté n'est pas très chaude pour faire de la doc... Pas grave, il y aura toujours la doc RHEL.
Bugs - The Ugly
Lack of basic multimedia support
Voir le "cahier des charges" de Fedora Core.
C'est comme si il reprochait à GNU/Linux de ne pas être proprio...
Verdict - The Editor's Opinion
A nice system, but I can find no reason to use it instead of other distributions
Quelle bêtise. C'est typique des testeurs. Il font un test durant 3 heures dont 20 minutes pour configurer yum. Forcément, ils ne retiennent que ça. Yum je le configure à chaque fois que je monte en version : tous les 6 mois. 20 minutes tout les 6 mois pour avoir mplayer, mpg32, c'est claire que je m'en fous complètement.
Es-ce qu'un jours les gens sauront que Fedora ne s'attaque pas au marché du desktop ?
C'est pourtant pas compliqué, c'est expliqué sur le site web de Fedora.
[^] # Re: Installation réseau?
Posté par 007 . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 2.
Oui (NTF, ftp, http, pxeboot et avec FC2 : vnc):
https://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/x8664-m(...)
C'est la doc RHEL 3 (grosso-modo la même chose que RH9).
Par contre pour FC2 qui a un noyau qui ne tient pas sur une disquette, il te faut récupérer vmlinux et initrd.img de l'image http://fr2.rpmfind.net/linux/fedora/core/2/i386/os/images/diskboot.(...) et les mettres sur le disque dur par exemple.
Puis dans grub (par exemple) ajouter :
title Fedora Core 2 install
root (hd0,0)
kernel /vmlinuz initrd=initrd.img ramdisk_size=8192 askmethod
initrd /initrd
[^] # Re: C'est quoi ?
Posté par 007 . En réponse au journal SSA dans gcc. Évalué à 0.
Misère.
# nptl
Posté par 007 . En réponse au journal NPTL et Gentoo. Évalué à 3.
Heu nptl pour Mandrake c'est à partir de Mandrake 10.0. Nptl a été fourni en premier par Red Hat (RH9). Normal, ils l'ont développé.
> J'ai l'impression que le système est un peu plus réactif.
> Quand pensez-vous ?
C'est psychologique alors.
nptl c'est bien :
- pour les développeurs
- pour les serveurs avec plein de thread (apache 2, serveur java...).
C'est l'interface linuxthread qui est utilisé par défaut. FC3 utilisera l'interface nptl par défaut. Donc plus rien à faire pour avoir nptl. Conséquence : incompatible i386. Il faut passer à i486 (c'est en cours de discution sur la mailing devel).