matiasf a écrit 1969 commentaires

Moi, pour le stable, je prend du vieux. Pour le boulot je suis sous RH 7.2 avec tout les errata (et toujour un bon vieux kernel 2.4.9-34 de RedHat).

Pour un usage perso j'ai les errata RH plus des conneries persos qui rendent la bécane moins stable, moins cohérente et moins maintenable (rien de dramatique).

Je pense passer sous RH 8.0 dans 3 mois (lorsqu'il y aura quelques errata) mais uniquement pour un usage perso. Au boulot on reste sous RH 7.2 qui donne satisfaction.

En fait, toutes les "vieilles" distribes sont stables.

Les trois sont aussi fiable après apprentissage.
Une fois que tu connais une procédure pour faire planter la distribe, tu la notes dans un cahier et tu ne l'utilises plus. Là t'as une distribution super fiable.

C'est beau le free software.
Tu pourrais mettre une url ?

> ils auraient pu prévénir avant de mettre devant le fait accompli, qu'il s'agisse des betas ou de la release.

Comprend le problème aussi. Faire un "look and feel" commun à Gnome et KDE était quelque chose de "stratégique" au niveau communication de RH. Si RH ne masque pas un peu ces plans (surtout s'il sont bons :-) ) il n'ont plus aucun effet de suprise et Mdk (par exemple) sort les inovations de RH en même temps que ... RH.

> Mais je ne suis pas sur que les développeurs Gnome seraient très contents si Mandrake présentait son Gnome utilisant par défaut Konqueror, Kmail et Kripa au lieu de Mozilla ou Galeon, Evolution et Gimp.

Si Mdk le fait, je n'utilisais peut-être pas la distribe mais çà ne serait pas un scandale. Il font leur jobs pour séduire un max de client. Et vu le nombre de plaintes sur linuxfr de la RH 8.0 , Mdk devrait y réfléchir.

> Je ne serais pas surpris qu'à terme, Red Hat supprime KDE complètement car leurs utilisateurs ne comprendront même pas pourquoi il y a deux desktops alors qu'ils ne voient pas la différence.

C'est un vrai soucis effectivement. Mais, je me répète, il n'y a pas que RedHat.

Et kde.org peut proposer des *.rpm pour RH 8.0 sans les modifs de RH.

Respect pour Debian.
Mais l'introduction précoce d'un gcc "typé gcc 3.0" a aidé Debian. Comme Debian aide les autres distribe. Bref, c'est une communauté.

> imagine maintenant que tu aies konqueror et kmail par default comme apps dans ton gnome tu saisis mieux le probleme ?

Imagine que maintenant tu n'aies plus galeon et evolution par défaut sous KDE ... :-)

RH aurait pu proproser un truc du style :
1) app conseillé par RH
2) app gnome
3) app kde

Ils n'ont fourni que 1) et j'admet que c'est regrettage.

Mais pourquoi ne pas ajouter aussi :
4) app CDE
....

Remarque, les Unix commerciaux vont majoritairement proposer GNOME (Solaris, AIX, HP-UX) et rien pour KDE (même pas une lib qt !) ! De plus, les Unix commerciaux c'est pas evolution par défaut, mais evolution Uniquement ! Il y a ici un "combat" plus important pour KDE.


Si les modifs RH ne plaisent pas, il faut prendre une autre distribe, faire de la pub pour Mdk par exemple en disant que KDE est meilleur sous Mdk 9.0 que sous RH 8.0. Mais allumer RH de cette façon sur leurs modifs n'est pas la bonne voie et n'apporte rien à KDE.

> tu as au moins la décence de prévenir les mainteneurs du projet initial. Question de politesse.

Faut pas faire comme si la RH 8.0 tombait du ciel du jour au lendemain.
Il y a eux deux betas et la première date du 3 juillet 2002. Soit presque 3 mois avant la sortie de la RH 8.0.


Enfin, il y a des distribes qui poussent KDE plus que GNOME (Suse, Mdk (moins maintenant il me sembl), etc... ) et personne critique le traitement de faveur qu'il font pour KDE.

RH a fait de petites modifs (il ont principalement fait un nouveau theme). D'ailleur il n'ont pas assez de dev KDE pour faire de grosses modifs ! Le autre comme Xandros, Lindows vont faire des grosses modifs de KDE (sans prévenir KDE, sourtout pour Xandros) et personne gueule?

Imaginons que RedHat ne fournisse plus KDE. Le plus gros perdant serait KDE et pas RedHat. GNU/Linux est en cours d'adoption. Beaucoup prennent RedHat car déjà très utilisé. S'il n'y a pas KDE, il feront sans (sourtout en entreprise où l'utilisation est orienté serveur et où tu ne peux pas d'amuser à comparer un RH 10.2 sans KDE avec un Mdk 11.2 avec KDE).

Franchement je ne comprend pas ce déchainement sans fondement contre RH (Je ne dis pas çà particuliairement pour toi :-) ) .

> sont des ptits trucs sauce mandrake comme l integration de menu<->kde

Comme RH pour une meilleur intégration (selon leur interprétation).

Bref RH fait la même chose que Mdk et Debian mais dans leur cas c'est un fork et pour les autres c'est des gentils.

> Qui plus est les paquet kde de mandrake sont fait par des gens de chez kde et pas n importequi

Jamais mis en cause la compétence des dev mandrake ni la pertinance de leur modification.

Bref, ils font comme RH. Peut-être en mieux (j'utilise pas Mdk et j'utilise pas KDE :-) ).
Mais c'est la même chose, le même objectif. C-à-d améliorer. Et je ne te ferai pas de repproches si tu trouves les améliorations de Mdk meilleurs que celles de RH.

RedHat a modifié KDE ET GNOME. Et les modifs sont aussi important pour GNOME (normal, ils sont familier avec GNOME) que pour KDE.
Va faire un tour les mailing-list gnome, regarde les packages *src.rpm et arrêter ce FUD anti-RedHat digne d'un Microsoft en pleine forme.

Par contre, tu peux trouver les modifs de KDE par RH à chié.

Enfin, RH modifie beaucoup plus GNOME que KDE car ils ont les compétences GNOME et les développeurs pour. Bizarrement le projet GNOME ne gueule pas sur RH.

La version RedHat 8.0 :
$ rpm -q -l -p kdelibs-3.0.3-8.src.rpm
kde-icon.xpm
kdelibs-2.1.1-path.patch
kdelibs-2.2.2-khtml-autoencode-ja-20011126.diff
kdelibs-3.0-noxs.patch
kdelibs-3.0-resize-icons.patch
kdelibs-3.0-rpath.patch
kdelibs-3.0.0-i18nfix.patch
kdelibs-3.0.0-ndebug.patch
kdelibs-3.0.2-alignment.patch
kdelibs-3.0.2-dock.patch
kdelibs-3.0.2-katetextbuffermultibyte.patch
kdelibs-3.0.2-ksyscoca.patch
kdelibs-3.0.3-dtfix.patch
kdelibs-3.0.3-lang.patch
kdelibs-3.0.3-redhat.patch
kdelibs-3.0.3.tar.bz2
kdelibs-3.1-iconthemes.patch
kdelibs.spec
keramik-20020802.tar.bz2

Le fameux patch RedHat :
$ cat kdelibs-3.0.3-redhat.patch
--- kdelibs-3.0.3/kdecore/kstandarddirs.cpp.orig 2002-09-01 17:31:30.000000000 -0400
+++ kdelibs-3.0.3/kdecore/kstandarddirs.cpp 2002-09-01 18:20:53.000000000 -0400
@@ -732,7 +732,7 @@
if (!strcmp(type, "pixmap"))
return "share/pixmaps/";
if (!strcmp(type, "apps"))
- return "share/applnk/";
+ return "share/applnk-redhat/";
if (!strcmp(type, "sound"))
return "share/sounds/";
if (!strcmp(type, "locale"))


Hyper violent comme modif. Mais y a pire (si si). C'est Mandrake !
SCANDALE !! HONTE SUR EUX !!!!

La version Mandrake 9.0 :
$ rpm -q -l -p kdelibs-3.0.3-30mdk.src.rpm
kde-lib64updates.patch.bz2
kdelibs-3.0-config-kdebugrc
kdelibs-3.0-filesharing.patch.bz2
kdelibs-3.0-iconssearch.patch.bz2
kdelibs-3.0-kdedesktop2mdkmenu.pl
kdelibs-3.0-kdedesktop2mdkmenu.pl-mdk-8.0
kdelibs-3.0-kio-kcookiejar.patch.bz2
kdelibs-3.0-kstddirs_kmenuedit_or_kmenudrak-mdk-8.0.patch.bz2
kdelibs-3.0-kstddirs_kmenuedit_or_kmenudrake.patch.bz2
kdelibs-3.0.2-add-cdrom-floppy-entry-in-kfiledialogbox.patch.bz2
kdelibs-3.0.2-default-document-path.patch.bz2
kdelibs-3.0.2-default-mdk-color.patch.bz2
kdelibs-3.0.2-default-preview-size.patch.bz2
kdelibs-3.0.2-distribution-list-use-klineedit3.patch.bz2
kdelibs-3.0.2-fix-dadou-crash-in-with-fam.patch.bz2
kdelibs-3.0.2-fix-item-in-kfile.patch.bz2
kdelibs-3.0.2-fix-kate-mem-leak.patch.bz2
kdelibs-3.0.2-fix-ktip-too-big-with-qt-305.patch.bz2
kdelibs-3.0.2-kfiledialogbox-add-mkdir-item-to-toolbar.patch.bz2
kdelibs-3.0.2-lib64dirs.patch.bz2
kdelibs-3.0.2-use-klineeditdlg-in-kfiledialog.patch.bz2
kdelibs-3.0.3-dont-add-dev-directory-entry.patch.bz2
kdelibs-3.0.3-fix-ask-flash-pluggins.patch2.bz2
kdelibs-3.0.3-fix-bug-in-kdialogbox-spearate-directory.patch.bz2
kdelibs-3.0.3-fix-crash-in-dirtree.patch.bz2
kdelibs-3.0.3-fix-crash-with-java-applet.patch.bz2
kdelibs-3.0.3-fix-cupdconf-dlg.patch.bz2
kdelibs-3.0.3-fix-ensure-visible.patch.bz2
kdelibs-3.0.3-fix-kate-mem-leak.patch.bz2
kdelibs-3.0.3-fix-kimgio-tiff.patch.bz2
kdelibs-3.0.3-fix-klistview-moveup-down.patch.bz2
kdelibs-3.0.3-kdeprint-use-klineeditdlg.patch.bz2
kdelibs-3.0.3-preview-icons-by-default.patch.bz2
kdelibs-3.0.3.tar.bz2
kdelibs-3.O-mdk-hicolor-index.desktop
kdelibs.spec
kmdbcreator.diff.bz2
ugc.fr.patch.bz2


C'est plus kdelibs c'est MANDRAKE_kdelibs.

Putain, là c'est claire, je traine trop sur DLFP.

> mais quand on fait un fork
J'ai du mal à considérer çà comme un fork.
Pour kdelibs-3.0.3-8.src.rpm le patch RedHat est explicite : kdelibs-3.0.3-redhat.patch

et le source de base est toujours la version officiel : kdelibs-3.0.3.tar.bz2

Il n'y a pas fork comme egcs était un fork de gcc. C'est-à-dire un truc comme "un appel à des développeurs pour changer l'orientation d'un projet car l'orientation actuelle n'est pas satisfesante". RedHat n'a pas fait de vrai fork et de plus ils ne veulent pas affecter les ressources nécessaires pour faire un fork. RedHat pourrai faire un fork de Gnome (ils en ont plus les moyens) mais pas KDE.
Enfin, si tu regardes les src.rpm, il y a plus de patch pour kdelibs de Mandrake que de RedHat ! Et je ne vais pas lancer le troll : "scandale Mandrake cré un fork de KDE".

Si les modifs faite sur KDE était un fork alors il faut dire que les modifs du kernel Linux par RH est aussi un fork (énormément de patch comme pour Mandrake etc...).

> c'est quoi au juste le "meilleur" outil ?
Je disais le meilleur selon l' "expertise" de RedHat. Mais le meilleur selon RedHat n'est pas forcément le meilleur pour tout le monde :
- Les gens sont différents
- RedHat peut se trompé
- Le meilleur aujourd'hui sera peut-être dépassé demain.

> Pour moi, KDE est "meilleur"
Utilise KDE. améliore KDE... C'est du free software man ! t'es pas dépendant de RedHat ! J'ai installé plein d'outils GNU (make, gcc, gdb, ddd, xemacs, etc...) sur HP-UX, DEC Unix sans demander la permission !

> apache 2 only entre autres
Damned, je lis partout qu'apache 2 n'est pas exploitable actuellement. Si ce n'est pas du FUD anti-RH, il faut donner des exemples concrès. Certain dise que certains modules ne sont pas disponibles. çà doit être vrais. Mais concrètement quel module manque pour votre usage (d'ailleur certains modules ne sont disponibles que sous apache ). Pour moi tout baigne (j'utilise apache 2 depuis un moment car j'utilise aussi subversion qui demande apache 2).

> <troll>Il y a 5 CD dans cette RedHat, mais encore moins de choix qu'avant... </troll>

Ce qui compte, c'est d'avoir le chois de prendre une autre distribe :-> .

Ben désolé pour ma remarque.

Le free software donne la liberté à chaqu'un de modifier/adapter un programme. RH a utilisé cette liberté. Reprocher à RH d'avoir utilisé cette liberté est scier la branche sur laquelle est assis le free software et la GPL principalement.

> Tout le monde est d'accord là dessus, même les plus acharnés défenseurs de RedHat.

Je suis un peu dans cette catégorie. Dans le fond, RH a raison. Par contre, je ne peux juger de la qualité du travail (Mais il y a eu 2/3 conneries ; qui n'en fait pas ?).

Il ne faut pas oublier que RedHat à modifié KDE ET GNOME (faire un tour sur les mailing list gnome) pour leur besoin. Et que RedHat ne s'est "acharné" uniquement sur KDE comme sous-entendu.

> et de la "présélection" sur des critères totalement arbitraires des applications par défaut.

Ben mois je trouve çà bien. J'ai pas envie de passer 2 semaines pour évaluer des clients mails. Je veux un distribeur qui dit :
- pour moi (RH) çà c'est le meilleur client mail pour un usage classique.
Je veux que par défaut les gens commencent avec les mêmes outils. Si plus tard ils trouvent mieux/plus adapté, ben il prennent autre chose et mieux.

Puis c'est le boulot d'un distributeur de faire des chois :
- mettre mozilla, virer Netscape 4.x.
- mettre très tôt ReiserFS ou pas. Attendre Ext3.
- virer au dernier moment les ACL car considéré comme instable.
- etc...

Un distributeur n'a pas obligation de packager tous les programmes. Un distributeur a le droit de donner son avis.
C'est au client final de faire le chois. Si la démarche de RH ne plait pas, regarde si Mandrake, Debian, etc... correspond mieux.

J'utilise GNU/Linux depuis longtemps (Linux 1.2 :-> ) et j'ai bouffé trop de temps a tester des applis. Je trouve que c'est un plus pour moi et je pense que c'est un gros plus pour un nouvel utilisateur.

Tout çà pour dire que je comprend que l'on critique le résultat final (d'ailleur j'ai pas testé la RH8.0) mais je ne comprend pas que l'on critique leur demarche actuel.

Je copie ici des éléments du test proposé par la news :
> yes, I am mostly a KDE user,

> I think Red Hat has done a good job modifying a Qt theme to look similar to GTK+'s BlueCurve. Whoever said that Red Hat modified KDE to look like Gnome is wrong. The BlueCurve theme is not Gnome's either. Red Hat wrote it pretty much from scratch. So, KDE applications now looks similar to Gnome's, and Gnome's applications are looking similar to KDE's. This is a good thing.

> Yes, the "About KDE" is not there anymore, and very correctly it is not. It is a completely reduntant, duplicated information for 99.9% of the users and it is there only to consume space. [...] RH did the right thing to remove that always-ever-present menu.


Et la conclusion sur la partie desktop :
> How well this distribution would do as a business desktop? Let me answer this like this:
Psyche is better than most of its Linux competitors, but still way behind in both the desktop experience and feature-set from both WindowsXP and MacOSX.

> ben le plus gros morceau a mon avis c'est le passage a gcc 3.2 quand meme ...

Pour RedHat, le gros morceau était de passer à gcc-2.96RH car RH voulais ce compilateur compatible source avec gcc 3.x.

> compilo maison (vous avez emarqué que j'ai pas cité red-hat :) )

Troll naze. Mandrake utilise/utilisait aussi gcc-2.96.

Voyons les incompatibilités des compilateurs officiels de RedHat :
2.95 -> 2.96 incompatibilité source/binaire, 2.96 compatible niveau source avec 3.0 (facilite le passage à gcc 3.x).
2.96 -> 3.2 incompatibilité binaire (pour c++).

Maintenant les incompatibilité de gcc :
2.95 -> 3.0 incompatibilité source/binaire.
3.0 -> 3.1 incompatibilité binaire (c++).
3.1 -> 3.2 incompatibilité binaire (c++)

Il y a d'autre distribe qui on fait moins d'incompatibilité ? (moins de 2 pour passer de 2.95 à 3.2).

Puis si gcc 2.96 est une "grosse merde", comment fait RedHat (et d'autre, Mandrake etc...) pour compiler toutes leurs distribes 7.x avec (7.0, 7.1, 7.2, 7.3 !).

Je pensais que ce troll était mort. Ben non...

>>> parler de la présence d'appli commerciales ou non,

>> - non

>SI!

Je voulais dire qu'il n'y a pas d'applis commerciales (pour la version personal au moins).

> C'est parce-que tu veux etre le premier a poster une news sur un truc qui ne t'interesse pas, et que tu estimes que que XXXXXX ca sux a mort, que les autres pensent comme toi.

J'ai voulu évité les trolls. T'y es insensible aparament. Et remarque que dans les commentaires il n'y a rien qui indique que c'est uns news pro-RedHat ou à troll (çà doit te changer des news Mdk).

> Si tu pouvais t'abstenir d'en reposter des comme ca, ca nous ferait plaisir.

MERDE ET MERDE ET MERDE.

Il y a un système de modération qui a laissé passer cette news. J'y suis pour rien. J'ai uniquement regretté qu'elle soit en page "autre". C'est pas la première fois que je poste une news. Elle passe ou elle passe pas. Ici, elle est passée. Alors va faire des reproches aux modérateurs.



Apparament, il n'y a que des Mandrakiens ici et je suis le seul (il me semble) a avoir proposé cette news.

Alors DLFP doit afficher la couleur :
- les news doivent être longue et tailler des pipes (Prendre pour exemple les news Mdk).
- les news sur les distribes doivent conserner que Mandrake et doivent être positive!
- les news techniques sur comment gagne 0,01 % en perfo et que 0,01 % du public de DLFP est capable de comprendre passe en première page.
- les news doivent copier l'information en intégralité pour éviter de demander un clic à l'internaute.
- ...

Merde quoi, découvrez ! Et quand vous aurez une ligne éditoriale claire, on pourra me faire de reproche.

> Si c'est vrai
c'est vrai

> quelqu'un connait les raisons ?
pas moi mais c'est un openssl très patché :
openssl-0.9.5a-64.patch
openssl-0.9.5a-glibc.patch
openssl-0.9.5a-ia64.patch
openssl-0.9.6-x509.patch
openssl-0.9.6a-add-baltimore.patch
openssl-0.9.6a-add-engine-version.patch
openssl-0.9.6a-add-ia64-asm.patch
openssl-0.9.6a-conf.patch
openssl-0.9.6a-redhat.patch
openssl-0.9.6a-soversion.patch
openssl-0.9.6b-mkdepend.patch
openssl-0.9.6b-sec.patch
openssl-0.9.6c-add-luna.patch
openssl-0.9.6c-aep.patch
openssl-0.9.6c-asn.patch.3
openssl-engine-0.9.6b-add-aep.patch
openssl-engine-0.9.6b-default-engine.patch
openssl-engine-0.9.6b-defaults.patch
openssl-engine-0.9.6b-hw_ubsec.patch
openssl-engine-0.9.6b-ubsec_failover.patch
openssl-engine-0.9.6b-ubsec_rand.patch

http://www.redhat.com/software/linux/flash/redhat6_5.html(...)

freshrpms.net :

sur http://psyche.freshrpms.net/(...) il y a des packages Alsa (driver et appli, mplayer configuré pour alsa par exemple) !.

Il est vrais que la compile d'alsa même en rpm c'est pas très sorcié (un rpm -ta alsa...tar.gz est souvent suffisant).

Tu as testé çà :

There is this new feature coming with RH8 that you create a directory called ~/.fonts and you throw in all your TTF fonts in there, and they get recognized automatically from the system! This is pretty neat, only problem is that not many people know about this feature.

Ne marche pas avec toutes les applis (OO par exemple) mais principalement avec Gnome 2.

Ce problème, c'est aussi les "gros" évènements qui ne faut pas manquer :
- Mozilla 1
- Openoffice 1
- GNOME 2
- KDE 3
- Apache 2 ?

C'est un chois récent de RH car avant il y avais toujours du support mp3. RH est dans le bon chemin. çà va pousser à utiliser les alternatives free software.
De même qu'il n'y a pas de flash ni de java etc.... Bref il y a presque rien de proprio (je dis "presque" car je n'ai pas une RH pour dire "rien").

Enfin, RH cible le "desktop d'entreprise" comme ils disent et non le multimédia.

d'après :
rpm -q -i -l -p ftp://ftp.free.fr/pub/Distributions_Linux/RedHat/redhat/linux/8.0/(...)

il y a :
/usr/bin/python
/usr/bin/python2
/usr/bin/python2.2

hors il n'y a que python 2.2 d'après :
rpm -q -i -l -p ftp://ftp.free.fr/pub/Distributions_Linux/RedHat/redhat/linux/8.0/(...)

Conclusion : C'est forcement python 2.2.

çà va prendre un peu de temps mais je crois que la majorité va reconnaitre les mérites du chois de RedHat (copieusement critiqué ici, On manque jamais une occasion de critiquer RH ici...).

Puis les autres distribes vont copier RedHat et le débat sera clos (comme souvent...).