matiasf a écrit 1969 commentaires

J'ai dit une connerie. soundcore.o est utilisé par alsa et OSS.
J'ai confondu soundcore.o et sound.o . sound.o est uniquement pour OSS (je ne parle pas de l'émulation OSS d'alsa).

> y'a 300 modules audio qui m'aiment pas, et quand je pense avoir réussis a "insmoder" soundcore et snd-emu10k1 correctement, y'a rien qui marche

Si tu utilises un driver snd-*, c'est un driver alsa, il te faut le module snd et non soundcore (qui est utilisé par OSS).

Regardes aussi /etc/modules qui charge des modules au boot.

> Maintenant, c'est clair que si frlinux avait l'ambition de faire un site de référence sur les distros Linux et même sur GNU/Linux en général, avec ce que cette attitude comporte de professionnel et d'impartial dans son exigence, ben c'est raté. Je pense qu'il va s'améliorer. Les nombreuses retouches qu'il a fait à son dernier article montre qu'il a remarqué qu'il y avait un problème. > A vrai dire, je suis extrêmement perplexe sur les raisons qui poussent RH à ne pas intégrer un tel système à leur distribution (ils n'ont qu'à intégrer apt-rpm, c'est déjà tout adapté pour leur distro), peut-être pourrais-tu m'éclairer à ce sujet ? un problème de syndrome NIH ? "syndrome NIH" ? c'est quoi ? Pourquoi il n'y a pas apt : réponse officielle et pas totalement convaincante : http://people.redhat.com/tcallawa/faq.html#apt-get C'est pas convaincant car rpm permet aussi d'installer "tout et n'importe quoi". Il ne doit pas être dure de faire en sorte que rpm n'installe que des paquets signés RedHat (il faut aussi ajouter une option type --nosigrh). De plus, rpm fournit tout le nécessaire pour contrôler le système (signature paquet, md5sum des fichiers). Il est toujours possible de contourner ces vérifications, mais c'est réservé à quelques "pointeurs". Faut noter le : - "Future revisions of RHN will add functionality to install new packages from Red Hat, not just upgrade existing ones." Côté outils dispos sur la "RedHat Linux" il y a up2date qui donne quelles informations : # up2date --help [...] --show-channels : Show the channel names along with the package name where approriate [...] --channel= : Specify which channels to use by channel label [...] --upgrade-to-release=<release-version> : Upgrade to the channel specified [...] --show-available : List all packages available that are not currently installed When operating in command line mode, specifying package names as arguments to the program will attempt to retrieve (and possibly install, based on your configuration) those packages. Version, release, and architecture details will be determined by the Update Agent automatically. Mais le fonctionnement reste trop centralisé sur rhn. On peut dire qu'il y a une volonté d'avoir des utilisateurs "captifs". Pour un "power user" c'est vraiment insatisfesant. Par contre, une entreprise sera peut-être satisfaite. Il y a aussi redhat-config-packages, redhat-install-packages mais ce sont des programmes qui "suck" grave (c'est un cauchemard). conclusion, ce n'est pas facile de voir où veut aller RedHat sur ce point. Mais il ne vont pas du côté des "power user". Les add-ons vont prendre de l'importance. Et pourquoi pas une nouvelle distribution qui serait une RedHat à 99 % avec un up2date légèrement adapté et quelle programme en plus. RedHat est libre, la voie est libre aussi. > hum, tu as pas coupé ma citation correctement, il n'y a pas de lien direct entre mes deux phrases (tu as d'ailleurs coupé aussi la deuxième). ma conclusion est la conclusion de tout le paragraphe sur RH ! Ooops.

> hum, beaucoup des points que tu relèvent sont quand même une histoire de gout huuummmmuuum... oui et non. Havoc (et beaucoup d'autres) a bien expliqué l'importance d'avoir une interface homogène pour toutes les applis. Je suis sur la même longueur d'onde. Je préfère des applis homogènes même si elle sont pas terribles que le "folklore" car chaque application a voulu faire l'interface en fonction de ses besoins. Dans le cas du "folklore", une application pris à part peut être une réussite totale mais l'ensemble des applications pour faire un OS complet et fonctionnel n'est pas satisfesant. Je dis ça pour les applis par défaut ou les outils indispensables. Je ne veut pas l'uniformité et l'utilisateur doit avoir le choix. L'utilisateur doit avoir le choix dans les distribes (et donc les applis/bureau par défaut), les applis, etc. Mais lui imposer la diversité, le folklore ... non. Tu peux me dire que c'est une question de gout, mais c'est assez largement admis et appliqué (voir la concurrence commerciale : windows, macos). Dans ce contexte, l'installeur et surtout le système de partitionnement manuel, n'est pas "bon". Surtout que ce ne sont pas des applis très utilisées et donc ne justifient pas le développement d'une interface spécifique (le mot est fort). Pour le "centre de contrôle de Mandrake", c'est plus discutable et pour le xdm "sauce" mandrake, c'est effectivement une question de goût (mais j'ai dit "(c'est subjectif)"). De même, proposer 4 terminaux, xterm (j'ai pas fait l'inventaire et c'est peut-être le seul cas) est "abérant". C'est abérant car c'est une distribe "user friendly". Que Gentoo ou Debian propose 4 terminaux ne me gène pas. Ceci n'est pas vraiment une question de goût mais plutôt de cohérence. > Le tableau de bord d'une Golf II (voire III) était à chier en terme de design, surtout en termes de look, pourtant la qualité perçue restait pas mal Ouais. Mais tout dans une Golf sent la Golf :-) et pas un mélange de saveurs sans rapport. Prenons Volvo, Mercedes, BMW, Alfa qui sont des marques attachées à leur identité et qui ont leurs adeptes (comme les distributions). Choisir entre ces marques, c'est une question de goût. Mais les sièges d'une BMW, la planche de bord d'une Golf, les panneaux de porte d'une volvo, le volant (surtout les anciens en bois avec les branches chronées) d'une Alfa dans une caisse de mercedes, c'est définitivement une faute de goût et ça a beaucoup moins de charme que la 403 de colombo. > PS: au fait, j'ai vu que tu as pris mon PS de news exactement pour ce qu'il est, à savoir, en ce qui te concerne, un clin d'oeil au porte-étendard (parfois passionné et "bruyant") de RedHat sur Linuxfr. Je préfère les gens qui affichent leurs convictions et on discutent calmement et honètement tout en respectant les convictions de chaqu'un. Être pro-RedHat, pro-Mandrake, pro-(n'importe quoi d'autre) n'est pas forcément un reproche. Je bossais dans l'automobile, chez Peugeot (je crois que tout le monde le sait depuis un moment...). Même si les gens qui travaillent chez Peugeot aiment cette marque, ces produits, ils respectent la concurrence. Si Renault ou Fiat à une idée, cette idée sera évaluée sérieusement pour voir si elle peut être profitable chez Peugeot. Tu as du remarquer comme les constructeurs adaptent/copient rapidement les bonnes idées (et c'est dans l'automobile où la lourdeur industrielle, les enjeux financier n'ont rien à rien à voir avec le logiciel surtout si il est libre). Dans le monde des distributions GNU/Linux, c'est que la guerre. Ce que fait l'autre est forcément mauvais et son expérience doit être ignorée. (frlinux, si tu lis il y a un message subliminal pour toi) Un exemple typique du malaise est Galaxy/bluecurve où il ne faut pas comparer les deux. Pourquoi ? Je trouve que l'idée de bluecurve est bonne. Si Mandrake la reprend, c'est bon pour Mandrake. Pour moi c'est claire. Mais comme c'est la guerre entre les distributions, il ne faut pas dire ça. apt4rpm c'est apt de debian. Je ne vois pas le mal. apt de debian est une bonne idée et apt pour rpm (ou urpmi) est aussi une bonne idée. Je ne dis pas que ce n'est pas apt car c'est apt pour .rpm et non .deb où qu'il y a une couche graphique ou ... Les "fans" de distribution doivent grandir et ne pas mépriser les autres. Si Mandrake nous tombe une meilleur distribution, tant mieux. Si Mandrake "tue" RedHat car ils font une meilleur distribution, où est le problème ? C'est embêtant pour les centaines d'employés de RedHat mais c'est bon pour les millions d'utilisateurs. Je viens de voir un de tes journaux : http://linuxfr.org/~anonyme512/2025.html > (tu parles de la RedHat), le plus visible est l'absence complète par défaut de logiciels multimédia (pas de mp3, de xine ou de mplayer) et de logiciel d'installation de logiciels (type apt ou urpmi) Si le point de vu est celui d'un utilisateur "normal", la critique du manque d'un logiciels d'installation de logiciels est discutable (quoi qu'il existe, c'est redhat-install-package mais il n'est pas encore au point :-( voir pas fini et je me demande s'il va être fini un jour car il ne me semble pas coller au business plan de RedHat). Si l'utilisateur peut installer "tout et n'importe quoi" (c'est fort mais c'est pour être compris), il peut "casser" son système. Par exemple après la mise à jour de galeon, ou l'installation de xine v4, gnucash ne marche plus. L'utilisateur "normal" ne veut pas ça et surtout ne sait pas réagir à ça. C'est au distributeur de la distribution de proposer ces mises à jour (je parle d'un point de vu utilisateur "normal"!). J'ai bien noté que depuis la 8.0, RedHat propose de faire des mises à jours sélective du système. Par exemple uniquement la mise à jour de mozilla. Mais ce n'est pas viable car comme tu le dis, le support n'est que de 1 an. Dans le domaine des mises à jour et de la gratuité, il y a que Debian qui tient la route. Enfin, RedHat a dit qu'à l'avenir il proposerait des mises à jour de logiciel (pas seulement des bugfix) via rhn. Je pense que ça va conserner "RedHat Enterprise" lorsque qu'il y aura une version desktop et pour mozilla, evolution, openoffice, etc. Bref pour la "RedHat Linux", avec le support d'un an, il y a une impasse pour les mises à jours logiciel ou add-on. Par contre, pour la version payante "RedHat enterprise", il y aura des mises à jour du type passage de evolution 1.2 à 2.0 ou openoffice 1.0 à 1.2. > up2date est passé en mode démo... il faut s'inscrire, répondre à des questions tous les deux mois pour pouvoir utiliser de temps à autre, quand les serveurs sont pas trop chargés, leur outil de mise à jour ftp ou http://updates.redhat.com/ http://www.redhat.com/apps/support/errata/ sont toujours dispos et ça ne manque pas de mirrors. Ça n'enlève rien à ta remarque. Mais ce n'est pas évident. Pour les distributeur, la vie est dure. Ce que j'aime pas dans le mode demo, ce n'est pas le questionnaire (vraiment pas méchant) tout les deux mois. Ce qui me gène, c'est que tout le monde n'a pas le même niveau d'accès à des mises à jours de sécurité (celui qui ne sait utiliser que up2date doit attendre que les serveurs soient dispos). C'est bête pour une boîte qui fait du logiciel libre et vante ces qualités pour la sécurité. J'ai le même type de remarque où les binaires des mises à jour ne sont pas disponibles gratuitement pour RedHat Enterprise alors que Microsoft propose les mises à jours de sécurité gratuitement. Néanmoins, RedHat vit correctement. J'espère que si les RedHat Enterprise leur rapportent beaucoup de pognon, il vire le mode demo et considère la gratuité totale de la distribution "RedHat Linux" comme un "mal" nécessaire pour leur implémentation en entreprise et l'évolution du logiciel libre dont il profite. Le support d'un an étant le "mal" que doit supporté l'utilisateur pour avoir un système gratuit. Pour un système complet et gratuit, c'est pas cher payé :-) . RedHat pourrait ainsi programmer up2date pour utiliser les mirrors et alléger la charge de leurs bécanes. > Politique de support de un an, ce qui entraine des MAJ fréquentes. A oublier pour le grand public Mandrake fait pareil. > En conclusion, je dirais que Mandrake me semble la distro la plus proche d'une utilisation grand public, Je ne veut pas nier ta conclusion. Mais si Mandrake "attaquait" le grand public avec la même cohérence que RedHat attaque le desktop/station de travail, leur distribution serait plus attractive. Surtout qu'il faut se méfier des capacités de RedHat et que Mandrake ne doit pas estimer ce marché comme acquis pour toujours. RedHat a fait une incursion dans le desktop et ils sont attractifs (il y a pleins de trucs qui "clochent" dans la 8.0 mais la 9 est aussi bonne qu'une 7.2 selon moi (c'est subjectif). Il y a rpm qui entre toujours en deadlock mais c'est beaucoup plus rare. Il y a un update sur ftp://ftp.rpm.org/pub/rpm/test-4.2/ . je l'ai installé depuis une semaine et auncun problème. Mais pas assez utilisé pour faire une conclusion) techniquement même s'il ne font pas actuellement d'offres pour les entreprises (support d'un an seulement). Pour le grand public et par rapport au mp3, RedHat a dit qu'ils pourraient payer une licence mp3 si elle était compatible avec la licence d'utilisation de leur distribution et des programmes qui utilisent mp3 (xine est sous GPL). Certains "statèges" de RedHat ont dit qu'il ne s'intéresseraient pas au "grand public" avant 2 ou 3 ans. C'est une durée largement suffisante pourque Mandrake fassent les bons choix statigiques. Et que Mandrake oublie la gratuité de la "RedHat Linux". Comme on le dit, ce n'est pas une solution viable pour le "grand public" ou le desktop en entreprise (support d'un an seulement). Mandrake a une bonne opportunité et ils doivent la saisir (c'est plus facile à dire qu'à faire). Mais si dans 2 ou 4 ans ils ne proposent pas un produit plus cohérent et un bon business plan, il sera trop tard...

J'ai testé rapidement une mdk 9.1. Pas assez pour une conclusion. Néanmoins le manque de """sérieux""" se retrouve un peu partout. - Le noyau utilise "boot off-board chipset first". S'il y a deux cartes ide, il ne faut pas installer lilo sur /dev/hda (valeur par défaut) mais sur /dev/hde pour que ça corresponde au premier disque vu par le bios. - L'interface de l'installeur manque de consistance. On a l'impression qu'il réinvente l'interface graphique au-lieu de se basser sur l'existant. - Le système de partitionnement manuel est "spécial". Il propose même tous les types de partion (une bonne cinquaine quoi), et le fs par défaut est ext2. - Dans installateur, à un endroit, je peux sélectionner en même temps des options qui sont normalement mutuellement exclusive. - Dans le centre de contrôle mandrake, ils ont réinventé la boite de sélection de fichier. - Si tu n'installes pas les outils de configuration, tu ne peux pas changer de bureau par défaut. - Par défaut, il y a 4 xterms différentes de disponibles !? - de façon général, le menu (d'équivalent du bouton "démarrer" de windows) est vraiment surchargé. - les sous-menus "programme" et "bureautique" sont mal choisi. Par exemple, gnucash c'est "programme" ou "bureautique" ? Ben en général tu fouilles dans les deux menus. - Le mode "expert" de l'installation est vraiment confus avec des options sans intérêt (on peut même faire l'installation avec un noyau 2.2 !?) - Il y a le login automatique (c'est douteux côté sérieux, mais bon...), mais j'ai pas vu de bouton "redémarrer" sous kde. De plus pour ne plus avoir de login par défaut, il faut être root (ou avoir son mot de passe). - leur xdm sauce mandrake est "raté" (c'est subjectif) alors qu'il doit "refléter" l'image de Mandrake. - A l'installation on peut activer acpi. Mais si ça ne marche pas, on fait quoi ? Je ne parle pas d'éditer un obscure fichier lilo (faut déjà booter pour ça :-)). Il faut refaire une installation. Je n'ai pas testé longtemps. Mais mandrake ne donne pas l'impression de savoir ce que c'est que la "usability". Faire une interface graphique, c'est un chose. Faire un ensemble simple, cohérent et qui ne réinvente pas la roue, c'est plus compliqué. Le plus gros défaut est le manque d'homogénéïté. Pour être méchant, je dirais que le point fort est que c'est "joli". Faut bien noter je parle de l'impression donnée. Je parle de la "qualité perçue" et non de la "robustesse du moteur" :-) > En résumé, ces problèmes de qualité perçue ne représentent pas grand chose (à vue de bugzilla, il devait y en avoir pour deux semaines de boulot pour corriger et intégrer ces petits bugs) Permets moi d'en douter sérieusement. Par exemple dans le "centre de contrôle Mandrake" lorsque tu changes de modules il affiche une popup avec un message type "les modifications de ce modules seront perdues, voulez-vous continuer." alors que tu n'as pas fait de modifications. C'est pas un grave défaut mais en terme de "qualité perçu", c'est pas terrible. Ce petit défaut peut demander pas mal de boulot et il faut repasser par la chaine de validation. > Par contre, ça suppose de revoir un petit peu l'organisation au niveau de la sortie de la distro (il faut un espèce de fasciste détesté de tous Une distribution, c'est trop lourd pour se permettre de repousser la sortie. Comme tu fais l'analogie avec l'automobile, la sortie d'un modèle est exceptionnellement retardée. C'est exceptionnel et ce n'est pas dans un processus normal de sorti d'un produit. Mon sentiment (j'ai bien dit sentiment), est que Mandrake doit être moins ambitieux et se concentrer sur la qualité perçue, sur leurs produits spécifiques (*drake*) et tant pis s'il n'y a pas galeon 1.3, acpi, etc. Le problème n'est pas de retarder d'une ou deux semaines la sortie mais d'estimer si les objectifs qualités pour la distribe peuvent être tenus dans les délais. Car pour repousser une sortie, il faut de gros défauts (les commandes pour imprimer les manuels sont partis, etc, etc). Ça veut dire que tu t'autorise une sortie sans gros défaut mais avec des défauts de "qualité perçu".

> euuuuh oui. Mais dans ce cas la, à quoi bon installer une distrib avec un gestionnaire de paquet si je ne veux pas l'utiliser. Parqu'il n'y a pas que le gestionnaire de paquet par exemple. J'utilise une RedHat alors qu'un apt ou un urpmi lui fait cruellement défaut. Mais il n'y a pas que le gestionnaire de paquet dans ce choix... > Pourquoi tentes tu de me l'imposer ? Je ne cherche pas à te l'imposer. Relis bien. J'explique que selon moi la critique des utilisateurs de slack sur rpm ne tient pas. C'est tout. Sinon continues à utiliser une Slack, je m'en bat les beep (censuré). Comme tu te fout completement que je n'utilise pas une Slack. > Je n'ai pas dénigrer les autres distribs J'ai pas dit ça. Dis moi où alors. Et j'ai pas dénigré Slack. Sinon dit moi où. Je parle de la récurrente critique sur rpm des utilisateurs de Slack. > C'est comme si tu m'obligeais à acheter une voiture climatisée alors que je ne veux pas de clim parce que j'en ai pas besoin. Je t'ai pas obligé. Pour continuer dans ton analogie, pourquoi je ne prendrais pas une voiture géniale avec climatisation même si j'ai pas besoin de la clim ? Tu penses qu'il serait mieux que je prenne une voiture pas terrible mais sans la clim ? Comme je le montre, le système de gestion de paquet type rpm peut être "inhibé" si tu n'en a pas besoin. Comme tu n'es pas obligé d'utiliser la clim. Un utilisateur de Slack va dire : - "quoi? moi utiliser une Mandrake alors qu'il y a un système de gestion de paquet que je n'en veut pas? Mais vous êtes fous !" (Et je fais expres d'oublier le couplet sur les dépendances inutiles, etc...). C'est ça que je n'aime pas. De plus il y a un système de gestion de paquet sur Slack :-). Moins évolué que rpm mais il y en a un. D'ailleur je ne réfute pas l'argument comme quoi il y a plein de paquets plus ou moins inutiles dans rh ou mdk en fonction des profils. Mais qui peut le plus, peut le moins. D'ailleur sur ma bécane j'ai installé 670 paquets sur 1450 proposés :-) RedHat et d'autres essaient de faire des distributions assez polyvalente. C'est incompatible avec une distribe où tous les paquets sont utiles. Sinon tu ne propose qu'un shell, qu'un bureau, qu'un client mail, qu'un navigateur, tu évites de proposer un serveur apache car tout le monde n'a pas besoin d'un serveur web, etc... Question : Il n'y a AUCUN doublon dans la Slack (style exim et sendmail, xterm et rxvt, etc)? Tu utilises TOUS les paquets de Slack ? PS : te sent pas obligé de quitter Slack, ce n'est pas mon propos. Et même si c'était mon propos, tu n'en ferais rien :-)

Ça va mieux en le disant. Le "chacun sur sa distrib et tout le monde est content... Point final." était ambigu et mon interprétation fausse.

> Sur ce, chacun sur sa distrib et tout le monde est content... Point final.

Absolument,
Absolument pas d'accord.
Une distribution est constituée d'au minimum 95 % de code de la "communauté". Le reste (et 5% c'est un très gros maximum), est spécifique à la distribution.
L'utilisateur d'une Slack/GNU/Linux/XFree/etc est à 95 % le même qu'un utilisateur de Mandrake. Faut pas dresser des barrières là où il n'y en a pas.

Si je vois une question sur php, je vais pas demander "pour quelle distribution?" avant de répondre.

J'ai eu quelques échanges de mail avec un "fan de Mandrake" alors que je suis un "fan de RedHat". Chaqu'un a expliqué pourquoi il vénére "sa" distribution et pourquoi il vomit l'autre (c'est une caricature). L'échange a été profitable pour nous deux.

Peut-être qu'un jour tu seras obligé de bosser sur RedHat. Peut-être que tu devras travailler sous Linux sur un PA-RISC et tu seras heureuse d'avoir une Debian sous la main, peut-être qu'un jour un ami va te montrer les qualités d'une Mandrake et tu vas te dire "Putain, mais c'est vrai qu'elle arrache grave cette distribe!", etc...

C'est comme pour les bureaux. C'est pas Gnome ou (exclusif) Kde. Beaucoup sont passés de Gnome à Kde et vice-versa.

> C'est bien de dire ca APRES mais c completement inutile.

C'est pas un site d'assistance. De plus le "complètement inutile" fait que celui qui t'as renseigné réfléchira à deux fois avant de recommencer. D'autant que tu as pas mal trollé plus haut. Tu allumes les utilisateurs de debian, tu suposes que "Houba houba Hop !" utilise une debian (ce qui est peut-être vrai, mais même moi qui lit beaucoup ce site, je ne le sait pas et je m'en fout!), tu dénigres le fait que debian supporte beaucoup d'architecture, tu descends mandrake, tu prends de haut ceux qui te répondes etc...

Et même ici, alors qu'on te donne un renseignement, tu trolles :
> n'en deplaise a qui que ce soit
> voir au dessus marre de me repeter
> Quand j'ai besoin d'un flic dans mon systeme, je vous appelle...
> Maintenant que j'ai reexplique pour la 42e fois au moins
> ta mdk il te reinitialise le systeme toutes les 2 heures et joue du banjo tous les matins a 6h pile

Y a un truc qui t'as gonglé avec une distribution que tu ne connais pas et que tu n'as presque pas utilisé. C'est pas une raison pour descendre la distribution (NB : j'utilise RedHat, je ne suis pas proMandrake et je suis un ancien utilisateur de Slack (ma première distribution comme pour beaucoup) :-)).

Je te donne un tuyau : pour avoir les messages de syslog je fais un "tail -f /var/log/message &". L'avantage c'est que tu ne modifies pas la conf et donc tu ne risque pas d'oublier de "défaire" les modifications. Si tu connais déjà ce truc, tu peux le dire mais pas méchament. Merci.

Ce n'est pas un coup de gueule principalement pour les commentaires plus haut, mais pour la réponse que tu fais à une personne qui te renseigne.
A l'avenir, soit plus courtois, Ooops, courtoise. C'est rare (trop?) une fille ici.

> Ce ne serait en aucun cas un problème si RedHat n'avait pas des outils par trop spécifiques du genre de GCC 2.96...

leur gcc 2.96, c'est un gcc 3.0 avec compatibilité gcc 2.95 (gcc 3.0 pour itanium principalement). Ce qui se compile sur gcc 3.0 et 2.95, se compile sous gcc 2.96 pour faire une transition en souplesse vers gcc 3.0. C'est l'objectif même s'il y a quelques problèmes. Et puis croix tu que RedHat peux sortir un compilateur avec de gros problème de compatibilité et sortir une distribe compilé avec ce compilateur 6 mois maximum après ? C'est plusieur million de ligne de code compilé ! Par contre la compatibilité est uniquement au niveau source pour le C++ (c'est le principal. non ?). Il faut aussi souligner que les sources étant dispos, mdk, conectiva, etc... on repris aussi gcc 2.96.
Maintenant RedHat utilise gcc 3.2 sans extensions. Les craintes d'une dérive proprio (ce qui est un peut "bête" avec un programme GPL) sont bien loin et je ne comprend pas qu'on en parle encore aujourd'hui. La vigilence voulais qu'il y ait des intérogations légitimes à la sortie de gcc 2.96. Maintenant, c'est du passé.

> Ce dont la plupart des gens ont peur, c'est que RedHat ne devienne un énième Microsoft

On peut imaginer que RedHat ait 98 % de part de marché. Mais les sources étant disponibles, les règles d'une concurence juste reste disponible. C'est le principale. RedHat est libre et la concurrence aussi. Toute structure de taille petite/moyenne peut faire un "fork" (c'est le mauvais terme, mais on me comprend) de la distribution. Si RedHat est dans le faut, le fork va réussir. Ceci est impossible avec microsoft.

Bref, le principal, que RedHat ait 99 % de part de marché ou non, est que RedHat fasse du logiciel libre. Et c'est toujours le cas.

> j'ai jamais encore trollé avec Féliciano, alors hop, je marche dedans

Ça va saigner :-)

> Il te suffit de faire un dpkg-reconfigure debconf et de choisir « noninteractive » comme front-end.

Je ne savais pas.

> Maintenant, une question : dans quel cas vas-tu laisser une machine installer automatiquement un soft

Exemple :
J'ai installé une Debian "pour voir". Ben au bout d'un moment mon état d'esprit était :
- "Mais tu me casse les couilles sévère avec tes questions à la con. Tu me la finis cette installation oui ou merde."

J'ai une anecdote. J'installe un woody 3.0r1. Y a mozilla qui "merde" à la configuration. Plus loin pour la configuration de la langue, j'ai dpkg qui essai de configurer mozilla (pourquoi?) et il reste boqué sur un truc du style "mozilla installing registry". J'ai perdu patience.

Et je n'aime pas ce mélange installation/configuration. Que l'installation du système nécessite une intervention manual, je le conçois. Surtout pour des services qui doivent fonctionner après l'installation du système. C'est typiquement le cas pour XFree, gpm, grub, etc... Mais ces cas sont rares. De plus pour une RedHat, ce n'est pas le paquet qui fait la configuration lors de l'installation du système, c'est anaconda. C-à-d un programme qui a le nécessaire pour détecter le matériel et configurer correctement XFree. Le paquet XFree n'a pas le nécessaire pour faire la configuration (sauf faire comme Debian en posant des tonnes de questions là où une distribe "intelligente" ne demande que de confirmer le matos détecté). D'ailleur une RedHat (rappel: je ne parle pas des autres car je ne connais pas assez) aucun programme ne nécéssite une intervention manuelle pour l'installer. Si tu as du temps, tu peux t'amuser à installer une redhat sur une partition avec (rpm --initdb /var/test ; rpm --root=/mnt/test toto-1.i386.rpm, etc...). C'est un peu lourd à faire, mais tu verras qu'il n'y a jamais une question de posée.

Tu veux souvent installer un programme pour lire la doc et après le configurer. Car de tout manière tu n'es pas en mesure de le configurer avant d'avoir lu la doc. Tu ne peux donc pas le configurer en même temps que l'installation.

D'ailleur, j'aime bien les récentes RedHat car elle ne lance pas un service qui vient d'être installé. Par exemple, tu demandes l'installation d'apache, mysql, postgresql, etc lors de l'installation et au boot, ces services ne sont pas lancés.

L'autre problème, est que la configuration à l'installation ne peut couvrir la plus part des paquets. Serait-il raisonnable de configurer bind lorsque je l'installe ? Es-ce au moment de l'installation que je fais rentrer les hosts, les domaines, etc... ? Idem pour apache. Que dire d'un programme comme evolution. C'est pas lors d'un "rpm -i evolution*" que j'ai envis de renseigner tout les comptes qui vont utiliser evolution. On peut dire la même chose pour mysql, postgresql, etc... lorsque j'installe postgresql sous debian, il me permet pas de configurer /var/lib/pgsql/data/(pg_hba.conf|postgresql.conf|etc).

Si j'installe un programme qui permet de configurer bind (par exemple l'excellent redhat-config-bind), c'est "stupide" de configurer bind lors de l'installation de bind puis de le configurer à nouveau avec redhat-config-bind que je ne peux installer qu'après l'installation de bind.

L'autre problème, est que celà interdit toute configuration poussée avec une interface graphique puisque l'installation doit pourvoir être faite depuis une console.

> Et pourtant, c'est souvent le cas. J'ai tapé 'apt-get install postfix', répondu aux deux-trois questions qu'il m'a posé, et j'ai obtenu un main.cf bien clean et adapté à ma config. Si seulement plus de mainteneurs pouvaient créer leurs paquets ainsi...

Tant mieux pour toi :-)
Mais ce principe, même s'il est parfois apprécié, n'est pas assez générique et il est facile de trouver ces limites.

> Bref, j'espère bien que les paquets « debconf-enabled » vont se faire de plus en plus fréquents...

Je ne connais pas debconf. Si c'est un moyen pour centraliser la configuration, c'est génial. Si c'est déclenché lors de l'installation, ça va me saouler :-)

> Je viens juste d'installer la 9.0

C'est un 9 (pas de .0).

> Ca chie dans tous les sens, le clavier est en qwerty pour une installation en francais

Le clavier reste effectivement en français dans anaconda durant l'installation (mais pas dans les consoles texte). Au premier boot, il est en français et tout est en ordre. Le problème existait aussi pour la 8.0.

> quand je reboot, les 10 premier arrêt s'affiche comme des merdes(utf) et les derniers sont bons...

"comme des merdes". Faut pas poussé. C'est les caractères accentués qui "chient" parfois. Mais je sais maintenant que tu as une installation en français :-)

> mozilla se lance pas parceque le profil est deja utilisé, c'est drole ca, j'avais jamais vu pour un premier lancement :)

T'as plus de détails ? Je n'ai pas vu de problème.

> Et le pire, tjs pas de about kde! Ils le font expres?

Oui il le font expres.

> De plus pour ceux qui disent que le about kde est pas dispo dans les applis kde mais que sous kde il y est, je l'ai pas vu, alors il est bien caché...

C'est comme sous Gnome. Click droit sur le panel puis "about (kde|gnome)".

Conclusion :
Tu n'as pas beaucoup de reproche à faire à une RedHat 9...

> l'environnement juridique du logiciel libre par Frédéric Couchet de l'APRIL est un must je trouve.

J'ai adoré.
Je pense (c'est un avi personnel) que la news doit passer dans "À la une". Surtout que j'ai vu plein d'amalgames, pour ne pas dire conneries, dans une news récente sur l'utilisation ou non de code BSD dans un projet GPL. Mélange droit d'auteur et licence d'utilisation.

> et si j'en veux pas moi, un système de package

Je ne connais pas assez deb pour commenter.
Par contre, pour rpm tu peux toujours faire des installations avec "rpm --nodeps" ou au pire avec "rpm --force" et dans ce cas c'est comme s'il n'y avais pas de sysètme de package. Si les scripts d'installation des paquets te gonfle, tu peux aussi utiliser "rpm --noscripts". Bref, tu ai libre.

> (quand on est organisé, on en a pas vraiment besoin).

C'est une remarque à deux bales.
Et avec les systèmes actuels il faut être sacrément organisé :
$ rpm -q --requires gnucash | wc
104 114 2219
$ rpm -q --requires php | wc
50 58 959
$

Soit tu est très très très intelligent, soit tu crées une base de donnée un peu équivalente à la base rpm.

# Et au moins, ses utilisateurs pètent pas plus haut que leur cul en dénigrant les autres distribs.

Tu ne viens pas de dénigrer Mandrake et RedHat ?

Ce que je ne comprends pas, c'est que les utilisateurs de slack attaquent toujours les autres distribe car elles ont un système de gestion de paquet. Si on prend rpm, c'est vraiment pas un problème (--nodeps, --force, utilisation de rpm2cpio... Mais je déconseille l'utilisation presque systématique de --nodeps ou --force).
Je ne pense vraiment pas que la "force" de slack vient de l'absence d'un système de gestion de paquet.
C'est une distribution plus simple qui n'a pas à composer avec des interfaces graphiques de configuration ou un public "amateur". C'est une distribution pour ceux qui connaissent bien les programmes installés. Mais tu peux avoir la même chose avec RedHat (je ne connais pas assez les autres distribution pour les commenter). Par exemple avec bind. Soit tu fais du vim, soit tu utilises redhat-config-bind (que tu peux virer avec un simple "rpm -e redhat-config-bind").

Et si les programmes de config de RedHat ne te plaises pas :
# rpm -q -a | grep ^redhat-config | xargs rpm -e firstboot desktop-printing

Et "voilà". Une ligne de commante et tu as une distribe "type" slack.
Si la gestion matériel te gonfle (c'est utilisé uniquement lorsque ton matériel change) :
# chkconfig kudzu off
OU
# rpm -e kudzu <kudzu-devel>

Après, il te reste /etc/sysconfig qui reste spécifique à la distribution. Ces scripts sont très lisibles et ne sont pas vraiment un problème.

Si tu n'as pas besoin des redhat-config* et kudzu, il est raisonnable d'installer une slack. Mais c'est pas parce que certaine distribution vont "plus loin" qu'une installation minimaliste, qu'elles ont tord. De plus, les distribes comme RedHat sont suffisament intelligente pour faire cohabiter intéligament, un mode de configuration "à l'ancienne" et un mode de configuration plus simple. Ce dernier est nécessaire pour conquérir de nouveau marché. Et oui, il n'y a pas que les élites.

PS: J'ai utilisé une slack durant 1 an :-)

> Sous RH ils ont la mauvaise habitude de faire ca ds le /etc/init.d/service avec un gros test du fond des bois.

Quels tests ?
Vérifier s'il y a une base de donnée avant de l'initialiser ?
Il n'y a rien dans les fichiers /etc/init.d/ pour configurer un service. Je connais bien RedHat et il n'y a rien pour configurer. Tout ce qui peut avoir, c'est un minimum de configuration mise en place pour lancer le service la première foi. C'est typequement fait avec postgresql pour les locales.

> Et c'est vrai que kudzu est le premier truc que je vire :)

Si ton matériel ne bouge pas, kudzu ne fait rien. kudzu c'est UNIQUEMENT pour le matériel ne ne s'occupe pas des services.

> 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....

Déjà, c'est /etc/init.d/mysqld, dans /etc/rc?.d/ il n'y a que des liens.

> Ds le genre goret....

Le genre goret, c' est :
- "if [ ! -d $datadir/mysql ] ; then"
Damned, c'est réellement goret.

> De ce coté la, j'aime bien les pre/post-install de debian

rpm permet aussi ça. Simplement il y a problème avec les scrypts interactifs comme le fait debian.
Ce n'est pas adapté pour des installations automatique où on ne demande rien à l'utilisateur.
De plus c'est réservé à des "spécialistes". Certaines questions lors de l'installation de debian ne sont pas à la portée d'un débutant. Le mieux dans ces cas, c'est de repousser la question dans un outil de configuration convivial où, le système étant installé, on peut fouiller la doc, surfer sur web, etc...

De plus, c'est scripts interactif de post-installation ne sont pas suffisant pour configurer un service et il faut toujours utiliser un outils de conf pour finir l'installation. Je préfère l'approche RedHat/Mandrake/SuSE etc qui est de faire les choses en deux phases bien distinctes :
- installation
- configuration

Alors que debian c'est :
- installation/configuration
- configuration encore une foi.

> Je peux t'aider si tu veux

Ce n'est pas bien, vilain garçon !
Tu sous-entends qu'il faut l'aide d'un spécialiste pour installer une Mandrake.

Ou alors que je suis trop con pour installer une Mandrake. Quoique...

> > PS: inutile de partir dans un troll là dessus, svp évitez les posts pro-RedHat (rpm -e matias)

> Super! On peut passer des attaques personnelles dans les dépêches maintenant? Génial!

C'est pas "top" élégant mais ce n'est pas très méchant. Surtout que je suis plutôt pro-RedHat et je ne le cache pas. J'aime bien la distribution, j'aime bien leur taff et patati et patata... Puis il y a plein de pro-Debian, pro-Mandrake, pro-Gentoo, etc ici pour compenser.

Ce que je n'aurais pas apprécié, c'est une phrase du type :
- "les anti-mandrake (rpm -e matias) passez votre chemin."

Ne pas être pro-bidule n'implique pas d'être anti-bidule.

> L'abscence de scripts de config automatique est d'ailleurs ce qui apporte une grande stabilite a cette distribution.

Ben là tu t'avances un peu.

Sous Redhat, une fois que l'installation est faite, il n'y a plus de "scripts de config automatique".
SAUF, kudzu.
Mais kudzu est un service. Donc tu fais "chkconfig kudzu off" et plus rien ne bouge dans ta config sans que tu fasses une opération manuelle.

Mais avec la dépendance sur redhat-release, qui est nécessaire à initscripts, j'ai plus rien. Je vais être obligé d'installer une Mandrake si je ne veux plus de cette fonctionnalité.

> c'est que fait RH, on installe tout, c'est pas grave

C'est pas ça le problème.

# rpm -q --whatrequires lvm
mkinitrd-3.4.42-1
# rpm -q --whatrequires mkinitrd
kernel-2.4.20-9
#

Tu fais une installation avec ta partion root sous lvm (c'est supporté par anaconda).

Tu vires lvm. rpm -e lvm (imaginons que la dépendance n'a pas été mise sur mkinitrd, aucun warning).
Plus tard, tu fais une mise à jour du noyau (up2date ou rpm -[UF]). Ben ton système ne reboote plus.

Notes qu'il n'y a pas cette dépendance sur raidtools. Car tu n'as pas besoin de raidtools pour booter avec la partition root sur un périphérique raid.

# rpm -e matias
error: Failed dependencies:
matias is needed by (installed) propaganda-redhat
matias is needed by (installed) troll-dlfp
matias is needed by (installed) find-and-crash-mdk
matias is needed by (installed) redirect2www_redhat_com_pub
matias is needed by (installed) redhat-release

Mais c'est donc vrai !

C'est une proposition pour me déniaiser ?

C'est un répétition mais il n'est pas nécessaire d'avoir devfs pour avoir le chargement des modules à la demande.
kerneld n'existe pas sous 2.4 (c'était pour 2.0 et 2.2). Mais le 2.4 support le chargement à la demande sans kerneld. Par contre les modules ne sont pas déchargé automatiquement. C'est pas grave, il suffit de faire un cron avec "rmmod -a" .

Je ne connais pas modconf, mais il n'est pas sûr qu'il charge les modules. Fait cat "cat /proc/modules" et regarde.
Par exemple :
snd-ens1371 15244 2 (autoclean)

Signale un module chargé "à la demande". 2 indique qu'il est utilisé.

dummy0 1884 1

Le module a été chargé avec insmod, manuellement. Même s'il n'est plus utilisé, un "rmmod -a" sera sans effet.

ide-cd 35164 0 (autoclean)

ide-cd est chargé à le demande mais n'est plus utilisé. un (ou deux) rmmod -a doit le virer.
Un petit test :
# rmmod -a
Uniform CD-ROM driver unloaded

Testé sur une machine sans devfs.

> le chargement des modules a la demande

Le chargement des modules ça existe depuis la nuit des temps (depuis Linux 2.0). Et pas besoin de devfs pour ça.