Patrice Fortier a écrit 146 commentaires

Les développeurs debian viennt tout juste de s'interesser au "status". La discussion est assez instructive sur le processus de discussion debian:

http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/initscrc(...)

En fait, c'est parti d'une demande pour etre complient LSB (je l'aime de + en + cette LSB :)).

Mais c'est clair que chkconfig me manque terriblement... :((

Il y a gnome 2.2, mais la gestion des dependances lors de l'install laisse a désirer (ca ne m'a pas installé le serveur X par exemple :)).

Mais il y a des trucs qui datent deja: La version de XFree est la 4.2 par exemple.
Debian reste fidele a sa réputation :)

Yep, et en plus il tourne sous root (woody et sarge).

Il y a aussi un paquet de mainteneurs qui ne savent pas utiliser update-rc.d et qui utilisent les valeurs par défaut (qui sont d'ailleurs tres nulles comme valeurs par défaut: S20 K20).

Donc je crois qu'on qu'on peut le dire, les init scripts de la debian sont franchements pourris :)

C'est par machine...
Avec 10 serveurs, ca commence a chiffrer, surtout s'il faut casquer tous les ans.
Petite note: a ce prix la c'est pour un serveur "simple", et tu as pas tous les services en terme de support (sinon c'est 750$ il me semble).

Personnellement j'ai du mal a accroché avec debian. J'ai des RH 7.x (et une 9) que je dois passer en debian (j'ai deja une woody qui tourne), et j'ai l'impression de revenir qq années en arrière pour tout ce qui est installation et administration courante de la machine - a part la mise a jour des patches de securité).

Bref, a part une machine que je dois passer en RH ES (debian est pas certifiée oracle), je vais passer les autres serveurs en debian, mais j'y vais a reculons...

AMHA, Rawhide et Fedora, c'est la meme chose maintenant.

Ben si tu as une partition avec plein de divisques, et que tu es un cinephile en culotte courte, tu peux te sentir concerné par ce test ;-)

Ca montre qu'il faut pas utiliser le mode journal avec ext3.
Ce que personne ne fait d'ailleurs.

Le perdant est plutot ext3 avec le mode journal.
Avec le mode ordered, qui la config sur 99% des machines, puisque celle par defaut, les perfs sont juste moyenne.

C'est plutot les perfs de reiserfs qui m'ont surpris...

A faire tourner des services qui ne sont pas suffisament utilisés pour justifier de les faire tourner en mode demon (ssh par exemple ds mon cas, et un ou 2 autres).
C'est clair que sur une station c'est aussi la premiere chose que je vire.

> Pour inetd/xinetd, c'est vrai (en tout cas sur la Woody).

Je parle bien de la woody.

> Pour ce qui est de logrotate: faux problème, il est désormais installé.

Comme pour xinetd, il est installé, mais pas utilisé. En particulier pour tout ce qui concerne syslog (ce qui fait la majorité des fichiers de logs générés chez moi), c'est traité par des scripts dont certains sont vraiment douteux.

Pourquoi ne pas utiliser ces outils qui existent depuis longtemps et qui ont fait leurs preuves?

> Pour ce qui est des runlevels: précise, je n'y décèle pas de problème.

Il n'y a pas de vrai problème, c'est juste que suivant la politique debian (ca a ete decidé comme ca alors on voit pas pourquoi changer), les runlevels 2345 ont la meme utilité. Pourtant sur la grande majorité des un*x, le 2 est un multi-user sans reseau, 3 avec reseau, et le 5 avec une interface graphique en plus.
D'une part, qd on est habitué ca perturbe (mais je suis douillet :)), d'autre part, ce sont des recommandations qui sont ds la LSB, et finalement c'est sympa de ne pas aller ds /etc/rc?.d si on veut passer de 3 a 5 par ex.
Une des raisons (la plus valable d'apres moi) pour ce schema, c'est que l'utilisateur fait ce qu'il veut (*), mais si je fais les modifs necessaires et que j'ai a upgrader un package ou en installer un nouveau, il faut ensuite que je refasse le boulot.

(*) Une idée maitresse de la politique Debian, dont l'origine doit etre une absence totale de concensus lors des choix de config par défaut, et qui conduit en général à des valeurs absurdes, suivies de la petite note: "L'utilisateur fera comme il lui plait".

> Pour chkconfig, je ne connais pas. La merde infame, c'est update-rc.d? Si oui, je suis assez d'accord maintenant quand je désactive un service temporairement, ce qui ne se pratique pas tous les jours, on peut aussi faire un "service stop", non?

yep. Mais des fois du veut desactiver un service pendant une periode plus longue (les vacances par exemple), sans avoir le risque de le redémarrer si ta machine doit rebooter (coupure de courant pendant la nuit depassant le temps autorisé par l'onduleur - ca arrive presque jamais, mais faut prevoir).

> sur un serveur tu rebootes rarement et tu devrais contrôler au delà d'une couleur rouge ou verte.

Sauf qd tu es persuadé que tout fonctionne bien au moment ou tu reboot (ca m'est arrivé une ou 2 fois cette année, et c'est incroyable ce que ca fait gagner comme temps :)).

> Les points soulevés ne sont que des détails,

Oui.
Enfin, pour ldap en root, xinetd et logrotate c'est plus que du detail pour moi. Ce sont des outils qui existent depuis longtemps et qui facilitent enormement l'administration d'un serveur. Qd j'ai proposé mon aide sur la liste debian-devel on m'a envoyé bouler...

Sinon je suis d'accord avec toi (d'ailleurs j'ai gardé un serveur sous Debian et j'essaie de m'adapter :)).

Pour RH ils ont pris le meme schema que la debian actuelle.
Rawhide (unstable), RH std (a priori qd meme plus stable que la testing et avec un support pendant un an), RHEL (stable).

- Avoir un viel inetd au lieu de xinetd. On peut effectivement installer xinetd, mais la config est faite sur le modele de inetd.conf (sans utiliser un rep. /etc/xinetd.d qui permet de faire les install de nouveaux services en douceur - ie: sans modifier /etc/inetd.conf)
- AVoir logrotate et pas des scripts de merde qui bidouillent avec cron
- Avoir une gestion cohérente (LSB?) des runlevels
- Avoir un outil aussi pratique que chkconfig pour desactiver temporairement un service (l'outil fourni par debian est une merde infame - la valeur de 20 par defaut pour l'arret et le demarrage m'a toujours fait rire)

Dans le genre "trucs a la con qui ont l'air d'avoir aucun interet mais en fait si!", le petit OK vert ou echec rouge au demarrage du système. Qd tout est vert on a effectivement l'impression que ca sert a rien...

Bon, apres il y a des details sans importances, par exemple le demon ldap tourne sous root, des babioles comme ca quoi...

Pourtant j'essaie regulierement de m'y mettre, mais bon a chaque fois c'est toujours aussi douloureux.

ouais. Je viens de decouvrir ce petit bijou, et la conclusion immediate a été: Il me faut une clé USB :))

Comme je l'ai dit un peu plus haut je suis passé a Debian recemment (2 semaines) suite au changement de politique pour les patches de securité de RH. J'utilise RH depuis la 3.0.3. J'ai bien fait des incursions sur d'autres distribs comme Mdk, et debian, mais je suis toujours revenu a RH (avant c'etait slak).
APres une install, il y a 2 ou 3 repertoires a pruger violemment (comme les /etc/rc?.d/ :)), mais apres c'est un peu pareil que partout. Les changements se font a la mano (j'ai pas non plus confiance ds les interfaces graphiques).

RH a un peu l'habitude ds mettre un peu partout /etc/sysconfig/ pour les options des services, etc. C'est un peu chiant la prmiere fois, mais bon, on s'y fait vite, et les options par defaut ne sont pas si mauvaises.

Chez debian, c'est l'inverse. Tout a ete reduit. Ca donne l'impression de revenir qq année en arriere. C'est plus simple, y a pas de fioritures, et c'est l'admin qui doit etre sensé mettre ses parametres par defaut.
A la rigueur j'ai trouvé ca assez chiant.
J'ai toujours pas compris ce qui posait probleme ds le terme "parametres par defaut".
[ ] c'est pas un boulot interessant
[ ] on a pas reussi a se mettre d'accord, alors on a laissé des valeurs de merde
[ ] si t'es pas 3l337, installe autre chose

Je donne 2 exemples, mais j'en ai trouvé des tonnes:

- Pour la gestion des services, RH a chkconfig, qui donne une idee des moments ont sont lancé les services. C'est qu'une indication, ca se change si l'admin est pas satisfait. update-rc.d donne S20 et K20 et demerde toi.

- Un autre pour la route. Depuis que je connais unix, les run levels sous sysV sont bien defini. Ben pas sous debian: les RL 2,3,4,5 sont laissé a la charge de l'utilisateur. Ca sert a quoi d'en avoir alors si tous les service (meme [xg]dm) sont lancé en 2?

Pour les fichiers de config, il y a aussi des trucs chiants chez RH. Par exemple, si tu install mysql, il va te créer la base ds le /etc/rc?.d/mysql avec un gros test au debut de start(). Ds le genre goret....
De ce coté la, j'aime bien les pre/post-install de debian (avec debconf).

Je ne parlerai pas des apt/rpm, j'ai planté les 2 facilement, et ils ont tous les 2 leurs avantages et inconvenients.

Mais je suis tout a fait d'accord avec toi, ca serait bien d'avoir (de stocker?) les bonnes choses de chaques distribs au nivo des config. Je suis persuadé que je garderai qq part une RH pour voir quelles sont les bonnes choses qui sont a la mode :).
Il y a aussi des bonnes choses sous Mdk, mais cette distrib n'est pas assez orientée serveur a mon gout. C'est pour les avant-gardistes :)

Le monsieur parlait de la Mdk 9.0, pas 9.1...

Je me suis toujours méfié des x.0 :)

Je mattrais qd meme un bemole en ce qui conserne les scripts de config automatiques sous RH. Je suis en train de tester une debian (la majorité de mes machines sont sous RH), et j'ai bcp apprécié le script post-install. Ca permet de de configurer un service juste apres sont installation.
Sous RH ils ont la mauvaise habitude de faire ca ds le /etc/init.d/service avec un gros test du fond des bois.

Ya plein de truc que j'ai pas aimé chez debian, mais ca c'est tiptop!
Et c'est vrai que kudzu est le premier truc que je vire :)

> Des paquets binaires sont disponibles pour 8 distributions.

Je connais un projet qui commence par un G et qui en est a la version 2.2.1 qui devrait en prendre de la graine....

Il y a des packages gnome 2.2 pour la woody (il y a meme un lien sur la page de gnome).

J'ai essayé garnome, et effectivement gnome 2.2.1 cohabite plus ou moins bien avec le 2.0 qui est installé en local sur ma babasse.
Par exemple, gnome-term ne fonctionne plus si j'utilise gnome 2.0 :(.

En plus garnome install vraiment tout de gnome, ce qui est pas vraiment ce que je veux.

Mais bon, apres avoir lu les mailing lists, je vais deja me considérer heureux d'avoir une version 2.2, vu que pour RH et autres (a part la debian), il faudra attendre une nouvelle version de la distrib pour en beneficier en packages...

> Pour l'homogénéité, si tu veux parler de mélange gtk1/gtk2, va falloir mettre le retour arrière et comparer avec kde au moment de la transition qt1/qt2, c'étiat probablement le meme bazar

Ca s'est bcp moins resenti car ds KDE tu as les applis de base de fournies. Donc qd tu passes de KDE 1 a 2, tu as basculé 90% des applis importantes.
Comme ds gnome la politique est de ne pas vraiment avoir d'appli officielle (ce qui est un avantage ET un inconvénient), c'est bcp plus laborieux.

Par exemple, comme lecteur de mail tu as evolution, sylpheed, balsa (et surement plein d'autres)... Ca fait deja un certain temps que gnome 2 est sorti, et seul balsa utilise gtk 2. Et des exemple comme ca, je t'en amene une brouette :).

> oui, y a cette histoire de toolbar si tu veux, mais bon, c'est mineur et facile à corrier

C'est pour ca que tu considère que l'article est un troll. Tu trouve ces détails mineurs (comme la plupart des développeurs), et pourtant ce sont ces petits détails qui rendent une IHM consistante. Le fait que tu saches ou va se trouver l'onglet "configuration" ds une appli alors que c'est la première fois que tu la lance, c'EST important; que tu reconnaisses immédiatement à quoi sert tel icon ds un bouton parce-qu'il a la meme utilisation ds une autre appli, c'est important. C'est une foultitude (j'aime bien ce mot :)) de détails comme ceux-la qui rendent un desktop homogène.
Note que, non seulement cela se voit essentiellement du point de vue utilisateur pur, mais en plus, c'est vraiment un boulot chiant a faire pour un developpeur.

Relis l'article de ce point de vue la, et il prend une autre dimension.
Relis-le en mode "je me fais chier a bidouiller des configs pour optimiser mes serveurs toute la journée, la dernière chose que je veuille c'est avoir a me faire chier sur ma machine perso le soir en retrant du boulot".

> Pour l'engueulade des codeurs de gnome qui sont pas foutus de se sortir les doigts et de faire un file selector correct, c'est totalement déplacé,

Absolument pas.
C'est une critique majeure pour un desktop. C'est une widget que tu vois ds tous les softs, qui sert tout le temps, qui est indispensable, et le c'est le dernier truc qu'a envie de recoder une equipe telle que celle de sylpheed ou evolution.
Paradoxalement, c'est une des plus gratifiante, vu que tu vois ton travail ds toutes les applis :).

> meme si c'est un peu la honte de pas avoir ed file selector correct.

Merci de dire la meme chose que moi avec des termes différents. ;o)

> que je sache tu leur as rien donné du tout, donc t'es pas vraiment en droit de les critiquer parce qu'ils ont pas envie de bosser sur un file selector.

J'ai bossé pendant plus d'un an sur gtk, et je me suis engueulé avec Owen Taylor juste avant la sortie de la version 1.0, ce qui m'a valu de ne pas apparaitre ds les crédits.
C'est une expérience... particulière... Meme si je n'ai jamais participé au dev de gtk pour la gloire ou les femmes :).

Ceci étant dit, je ne vois pas en quoi je n'aurais pas le droit de critiquer le fait que pas mal des briques de base (tel un file selector) aient été fait à la va-vite ou baclés, hisoire de dire qu'il y en a un, si on passait à autre chose de plus sympa comme corba...

Franchement, a part le ton d'utilisateur aigri et désabusé, c'est qd meme une critique pertinante. Comptes le nombre de fois ou tu utilises un file selector, que tu utilises une widget d'édition de texte, et regardes ds les sources de gnome et des applis gtk combien de fois les developpeurs les ont réécrites, ou se plaignent que c'est buggé/incomplet (je suis abonné à une liste ou c'est un sujet récurrent pour certaines widgets - de la version 1 je l'avoue, mais je ne sais pas si ca a été corrigé ds la version 2, et pour le file selector, non).

Ce sont des problèmes qui ont été traités et réglés depuis longtemps sur KDE, et pas encore sur Gnome. Inutile de jouer les vierges effarouchées si on le fait remarquer après qq années.

> il écrit un article pour expliquer que gnome en comparaison est super compliqué à installer

Bah, deja il a reussi a trouvé les packages gnome 2.2 pour sa debian. Moi en cherchant pas mal, j'ai reussi a trouvé UN mec qui avait fait des packages pour la RH 8.0, et ils s'installent meme pas chez moi.
C'est pas une reflexion debian/RH, mais je fais juste remarquer qu'a part les sources, sur le site de gnome tu peux te brosser pour installer Gnome 2.2.

> Et franchement, quand tu grattes un peu tout le vernis trollesque de l'article, il reste pas grand chose.

On a pas du lire le meme article alors...
J'ai beau essayer d'utiliser KDE, j'y arrive pas. C'est vraiment trop moche. Et puis toutes les applis que j'aime bien, elles sont sous gtk. Et puis j'ai un theme gtk que je trouve super bôôôôh...
Malgré ca, je suis d'accord avec quasiment tous les points qu'il soulève.

Il n'y a vraiment pas grand chose d'homogène ds gnome. Et depuis gnome 2, c'est vraiment le bordel. T'as des applis en gtk 1, d'autres en gtk 2, c'est la merde pour faire fonctionner les versions 1 & 2 des themes en meme temps.

En regardant bien, j'ai meme l'impression d'utiliser des appli strictement gtk + le panel de gnome + nautilus (les jours ou j'ai envie de m'en mettre plein la vue seulement, parce-qu'au quotidien c'est un peu lourd - g qu'un PIII 600).

Hors l'article parle d'un desktop: Un envirronement homogène. Je suis désolé, mais actuellement gnome est aux fraises sur ce point.

> S'il sétait renseigné 10 secondes, il aurait su que la seule raison pour laquelle cette chose est encore là est que personne a vraiment pris le temps de bosser dessus.

Et c'est exectement ca qui est pitoyable de la part de l'équipe de gnome. En 6 ans, personne n'a trouvé le temps de faire un file selector ds gnome!!!
C'est une blague?
Et des fonctionnalités comme ca qui sont a moitié finies, et ou les gens les recode pour qu'elles soient complètes ou font des bidouilles pour contourner les limitations/bugs, il y en a un certain nombre.

Evidemment, coder un file selector correct, c'est moins "noble" que de coder un nouveau langage de haut niveau pour réécrire la version 5 de gnome....

Tant qu'a etre aigri, je vais en remettre une couche:
Qqn peut-il m'expliquer pourquoi l'équipe de gnome a jugée utile de virer sawfish (qui etait complet et qui fonctionnait bien) pour le remplacer par metacity? Ca donne vraiment l'impression que qd qqchose marche, on se depeche de le remplacer par autre chose :(((

> son article est un immense troll qui peut sembler bien fondé si tu lis vite fait,

Et pour cause... Il est bien fondé. Et encore, pour etre un utilisateur de gnome, je suis heureux qu'il ne s'y connaisse pas assez pour l'enfoncer plus.

Je comprends que cet article, blesse ton pauvre petit coeur de gnome, mais prends un peu de recule, pose toi, refléchi, et tu verras qu'il n'est malheureusement pas si loin de la vérité.

La seule critique que tu peux faire à cet article est de demander si
- La facilité d'installation
- gconf et le fait qu'il y ait des fichiers de config partout
- le fait que gnome soit tout sauf homogène
sont des critères primordiaux.

Pour moi non, et c'est ce qui explique que je l'utilise encore (pourtant ca me fait bien chier :))

C'est tres simple.
Intel fait des procs, et il faut bien tester leurs performances.
Qui de mieux que Intel pour faire un compilo totalement adapté a cette tache.

gcc integre peu d'optimisations spécifiques aux intel haut de gamme, et ses performances étaient jugées médiocres pour les versions 2.x. Lors de la sortie de icc 6, les benchs (on y revient toujours :)), montraient que icc enfoncait gcc ds a peu pres tous les domaines (jusqu'a ~40%, et ~25% pour VC++). Meme en mettant une marge de 10% sur ces chiffres, ca fait une bonne différence de perf...
Ce qui est amusant, c'est que, comme l'a noté qqn d'autre, icc 7 est plus lent que le 6...

D'autre part, comme le comparatif n'était pas fait par intel, ils ont testé aussi les athlon, et ces procs profitaient également des optimisations de icc 6.

Enfin, le code des compilos intel est truffé de licenses. Il ne peuvent simplement pas se permettre de le filer a des projets open-sources, et meme s'ils le faisaient, ces memes projets refuseraient ces contributions (car soumises a des licenses).

Il doit bien sur y avoir d'autres raisons, mais ca donne deja une bonne idée.

Hmmmm...
J'aimerai voir le texte de loi qui dit ca (et pas seulement la license, dont je doute de la valeur juridique).
Par contre le logiciel est protegé par un copyright, ce qui t'empeche déjà de faire un paquet de choses.

Je pense que cette phrase a été rajoutée pour tenir compte des locaux professionnels faisant parti d'une habitation servant de domicile.
ex: un cabinet de médecin se trouvant ds la maison ou habite ce meme medecin.