Re: [LONG] [TRÈS LONG] Re: Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
Le Fri 14/12/2001, Frederic Bothamy disait Erwan David wrote: Le Thu 13/12/2001, Nicolas Boos disait Traduction : En gros, make-kpkg te dit que tu n'as pas de modules (autres que ceux propres du noyau) dans /usr/src/modules. Après, make-kpkg passe à la suite, comme un grand. PS : /usr/share/doc/kernel-package/README.modules, limpide. bretagne:~ % less usr/share/doc/kernel-package/README.modules usr/share/doc/kernel-package/README.modules: Aucun fichier ou répertoire de ce type Manque un / au début ... Ah mince, tu es peut-être en stable ... Pas de chance, le fichier n'existe que pour testing et unstable. Bah dans quelques mois, woody deviendra stable ... ;-) Non, non j'avais mal fat un copier/coller... Je répond aussi à quelques autres courriels de Erwan David : ET pourquoi j'aurais des modules dans /usr/src/moduile ? si je patche le noyau je patche dans l'arbre, pas à côté... Parce que ce ne sont généralement pas tes propres patches qui vont à cet endroit, mais plutôt ceux de projets liés au développement du noyau (cela permet de garder le répertoire du noyau propre), mais pas inclus pour différentes raisons. Personnellement, j'ai nvidia-kernel-src, cdfs, lm-sensors, em8300, ftpfs et i2c (bon celui-ci est dans le noyau, mais cette version est censée être plus à jour). Et si un jour, je veux modifier mon noyau à la main, je ferai mes modifs directement dans les sources du noyau, à charge pour moi de faire attention quand je patcherai d'une version du noyau à une autre (de 2.4.16 en 2.4.17 par exemple) Ailleurs, il a également écrit : gpg: `Unknown Kernel Package Maintainer [EMAIL PROTECTED]' a été ignoré: la clé secrète n'est pas disponible gpg: [stdin]: clearsign failed: la clé secrète n'est pas disponible make: *** [stamp-buildpackage] Erreur 2 Bizarre, dans la documentation (AMA très bien faite, mais en anglais) (/usr/share/doc/kernel-package/README.gz), il n'est pas indiqué, dans les instructions rapides, de lancer un make-kpkg buildpackage. Peux-tu suivre les 6 étapes indiquées et nous dire si cela fonctionne ? (Il aurait également été judicieux de nous donner la commande à l'origine de l'erreur pour déterminer la cause exacte du problème) (cf. l'explication de cette erreur plus bas) Ah mais là il y a contradiction... Le Rationale dit l'avantage c'est qu'il n'y a qu'une commande à lancer on en est à 6... Quand j'ai lancé make-kpkg kernel_package ila raler que c'était pas une cible connu, et odonné une liste de cibles avec buildpacakge : builds the package... Je ne suis toujours pas convaincu de l'intérêt d'autant que ça a foutu pleind e bordel dans mon arbre de sources du noyau... -- Erwan
Re: Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
On Thu, Dec 13, 2001 at 11:27:07PM +0100, Erwan David wrote: Traduction : En gros, make-kpkg te dit que tu n'as pas de modules (autres que ceux propres du noyau) dans /usr/src/modules. Après, make-kpkg passe à la suite, comme un grand. ET pourquoi j'aurais des modules dans /usr/src/moduile ? si je patche le noyau je patche dans l'arbre, pas à côté... Parce que tu as installé un des paquets contenant un module, par exemple nvidia-kernel-src, ou (non testé) alsa-source... On parle de modules, pas de rustines. Il faut encore savoir de quoi tu veux parler (évidemment, si toi tu ne conçois les modules que comme des rustines sur le noyau monolithique, il y a beaucoup à faire).
Re: Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
On Fri, Dec 14, 2001 at 08:22:36AM +0100, Erwan David wrote: Mais les modules du noyau sont dans les sources du noyau. Ou alors il faut *aussi* prendre un noyau qui a été complètement coupé avec des modules d'un côté et les sources du reste de l'autre ? Pas tous. Pense à de grosses infrastructures, ou a des choses complètement externes. Ce n'est pas le cas d'un simple contrôleur disque (en Je veux mettre mon controleur de disque directement dans le noyau (c'est plus facile pour booter sans ce hack grossier d'initrd) ah non il est dans les modules ? Tu n'as jamais eu à compiler des noyaux et à les mettre à jour pour une tripotée de machines différentes, dis-moi ? L'initrd a cela de bien qu'une fois que j'ai précisé pour toutes les machines que je gère ce dont il a besoin pour démarrer (et pas dans le noyau, dans le fichier /etc/mkinitrd/modules), je peux installer le même noyau sur toutes les machines sans aucun souci. Et en compilant tout, je n'ai pas à recompiler le noyau pour chaque nouveau matériel. Depuis que j'ai mis en place l'infrastructure de make-kpkg, je fais tout sans souci. L'initrd n'est pas un hack grossier, c'est une solution pensée. Évidemment, c'est un canon pour écraser une mouche sur la machine personnelle d'un connaisseur, ce que je concède volontiers. Mais à un niveau plus grand, c'est une bonne solution. Installer le pilote de NVidia est extrêmement simple avec la méthode debian. -- JCD PS:Et la liste, c'est debian-user-french. Change ton alias.
Re: [LONG] [TRÈS LONG] Re: Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
Le Fri, 14 Dec 2001 07:46:38 +0100 Erwan David a gravé sur son écran à l'aide de son clavier: Je ne suis toujours pas convaincu de l'intérêt d'autant que ça a foutu pleind e bordel dans mon arbre de sources du noyau... Tu gardes ta méthode et puis c'est tout. Personnelement, pourquoi j'aime bien le make-kpkg : - Je peux compiler sur une machine dédié à ca et - Je peux déployer sans pb mes noyaux sur plusieurs machines. - Je peux revenir sans pb à un autre noyau si besoin est. - Je peux géré facilement mes versions de noyaux avec dpkg. - Je peux avoir plusieurs noyaux de mm version nommés différement. - Je peux inclure mes noyaux dans une arborescence debian pour pouvoir y accéder via mon source.list Tout ce que j'ai à faire c'est : - Récuperer et décompacter les sources (tgz ou deb) - cd source kernel - make menuconfig - make-kpkg -uc -us --flavour=desc --revision=rev kernel-image \ kernel-headers - dpkg -i kernel-image-desc-rev.deb Et puis voilà Librement, -- MEI Sébastien [EMAIL PROTECTED] CRI - ENS Lyon http://www.ens-lyon.fr
Re: Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
Le Fri 14/12/2001, Jean-Christophe Dubacq disait Depuis que j'ai mis en place l'infrastructure de make-kpkg, je fais tout sans souci. L'initrd n'est pas un hack grossier, c'est une solution pensée. Évidemment, c'est un canon pour écraser une mouche sur la machine personnelle d'un connaisseur, ce que je concède volontiers. Mais à un niveau plus grand, c'est une bonne solution. Installer le pilote de NVidia est extrêmement simple avec la méthode debian. Mais installer la patch de crypto on est encore plus emmerdé : puisque ça impose de modifier des outils user-land... C'est d'ailleurs pour ça qu'au boulot on a pris SuSE et pas Debian... En plus ton message donne une troisième suite de commandes.. Laéquelle est la bonne ? Par ailleurs je me demande comment avec les modules extérieurs à l'arbre du noyau, le make (x|menu)?config va s'y retrouver... Bref : y'a peut-être de bonnes idées derrière, mais le discours sur cet outil tantôt pour le novice tantot pour celui qui administre un parc hétérogène me paraît un peu alambiqué... PS:Et la liste, c'est debian-user-french. Change ton alias. Je réponds à l'adresse où ça a été envoyé... -- Erwan
Re: Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
On jeudi 13 déc 2001, Nicolas Boos wrote: Par ailleurs je trouve la doc de makke-kpkg absconse et je n'ai jamais réussi à comprendre comment l'utiliser. Par exemple (95% du temps) : make-kpkg clean make-kpkg --revision=1 kernel_package Trop dur. Mais, il me semble aussi que l'on a eu cette discussion il n'y a pas si longtemps déjà... En fait même si ça fait un peu plus d'un an que j'ai une distri linux, je me considère encore comme un débutant. J'ai compilé mes premiers noyaux récemment sur Mdk en traditionnel, sur debian à la debian, mais j'ai fait 5 compil en 3 jours. La faq debian est limpide, la doc de kernel-package également, la méthode deb est à mon avis plus aisée pour le débutant...qui a lu la doc ! Maintenant, en cas de souci à la compil, et c'est vrai pour toutes les compil, le réglage est plus ardu. Et si le débutant a plus de mal, voire n'y arrive pas, est ce la faute à la méthode ou au source (ou aux options de compilation) ? Lorsqu'une compilation échoue est ce la commande `make` qui est responsable ? -- jean-michel
Re: [LONG] Re: comment demarrer fwm2
Fabrice Eudes wrote: bonjour, j'ai pas suivi tout le fil de discussion, mais, sans rentrer dans des considérations pointues sur la méthode update-alternatives, pour les gestionnaires de fenêtres, il y a le paquet 'wmanager' que je trouve bien pratique ! Yesss ! Ton paquet m'a l'air bien sympathique !! Merci ! R.
Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
Le Wed, 12 Dec 2001 23:43:14 +0100 Erwan David [EMAIL PROTECTED] écrivait : Salut, [...] -- /usr/share/doc/kernel-package/Rationale.gz [...] C'est un mélange d'affirmations gratuites sur des avantages qui n'en sont pas (des tas de points que je sais parfaitement faire tout seul sans make-kpkg) ^^^ Toujours le même argument fallacieux. Ouais, toi, TU SAIS faire tout seul. Figures toi donc que le novice ou l'utilisateur moyen, lui, il ne sait pas (et bien même souvent, il n'a pas envie de trop savoir...). Au début du Rationale, on trouve : This is especially important to novices: make-kpkg takes all the steps required to compile a kernel, and installation of kernels is a snap. [...] En plus elle mforce un modèle de noyau : celui avec quasiment tou t en module. Je regrette sur lma machine je sais ce que j'utilise je n'ai donc quasiment aucun module. Ah bon? Si mes souvenirs sont bons, c'est bien toi qui choisis ce qui doit être modulaire ou non dans le noyau. Pas make-kpkg. Par ailleurs je trouve la doc de makke-kpkg absconse et je n'ai jamais réussi à comprendre comment l'utiliser. Par exemple (95% du temps) : make-kpkg clean make-kpkg --revision=1 kernel_package Trop dur. Mais, il me semble aussi que l'on a eu cette discussion il n'y a pas si longtemps déjà... A++ Nicolas
Re: Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
Le Thu 13/12/2001, Nicolas Boos disait Le Wed, 12 Dec 2001 23:43:14 +0100 C'est un mélange d'affirmations gratuites sur des avantages qui n'en sont pas (des tas de points que je sais parfaitement faire tout seul sans make-kpkg) ^^^ Toujours le même argument fallacieux. Ouais, toi, TU SAIS faire tout seul. Figures toi donc que le novice ou l'utilisateur moyen, lui, il ne sait pas (et bien même souvent, il n'a pas envie de trop savoir...). Et on lui file la doc de make-kpkg Par exemple (95% du temps) : make-kpkg clean make-kpkg --revision=1 kernel_package Trop dur. Mais, il me semble aussi que l'on a eu cette discussion il n'y a pas si longtemps déjà... Et bien entendu le novice va le deviner à partir d'un man qui présente les oprions une par une avec une description du genre : --revision number Changes the Debian revision number for the packages produced to the argument number. This has certain constraints: the --revision option only has an effect during the configure phase (in other words, if a file called stamp-configure exists, this option has no effect -- run make-kpkg clean or man ually remove stamp-configure and stamp-debian for it to have an effect -- I strongly suggest you run make-kpkg clean unless you know what you are doing). Additionally, official source package maintainers provide their own version numbers and data for the official uploads, and hence a number of things, including the Debian revision, is not modified by make-kpkg. If you happen to have an official source, (that would mean that the file debian/official exists), and want to use your own revision number, make sure you remove debian/offi cial before running make-kpkg clean for this option to have an effect. So, if you want to re-run make-kpkg with a different revision number, you have to make sure you start with a clean slate. Secondly, the version may contain only alphanumer ics and the characters + . (full stop and plus) and must contain a digit. (Look at the Policy manual for details). Actually, that is a lie: official kernel and modules maintainers have special dispen sation to use hyphens, but it is strongly depre cated for most people, since no sanitization of the version number is done, and dpkg and friends may choke on it at the end of the compile unless one knows what one is doing. Optionally, you may prepend the revision with a digit followed by a colon (:). The default is 1.00.Custom unless the env variable DEBIAN_REVISION_MANDATORY is set, in which case an error is generated if the revision is not set on the command line or the config file. C'est pour le novice ça ? Il faut être dévelopeur debain pour comprendre la doc ! Faut arrêtr de se foutre du monde. -- Erwan
Re: Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
Le Thu 13/12/2001, Erwan David disait Le Thu 13/12/2001, Nicolas Boos disait Le Wed, 12 Dec 2001 23:43:14 +0100 C'est un mélange d'affirmations gratuites sur des avantages qui n'en sont pas (des tas de points que je sais parfaitement faire tout seul sans make-kpkg) ^^^ Toujours le même argument fallacieux. Ouais, toi, TU SAIS faire tout seul. Figures toi donc que le novice ou l'utilisateur moyen, lui, il ne sait pas (et bien même souvent, il n'a pas envie de trop savoir...). Et on lui file la doc de make-kpkg Par exemple (95% du temps) : make-kpkg clean make-kpkg --revision=1 kernel_package Trop dur. Mais, il me semble aussi que l'on a eu cette discussion il n'y a pas si longtemps déjà... ben déjà ça ne marche pas : bretagne:/usr/src/linux % make-kpkg clean find: /usr/src/modules: Aucun fichier ou répertoire de ce type Bon...facile ? -- Erwan
Re: Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
Le Thu, 13 Dec 2001 22:37:58 +0100 Erwan David [EMAIL PROTECTED] écrivait : [...] Par exemple (95% du temps) : make-kpkg clean make-kpkg --revision=1 kernel_package Trop dur. Mais, il me semble aussi que l'on a eu cette discussion il n'y a pas si longtemps déjà... ben déjà ça ne marche pas : bretagne:/usr/src/linux % make-kpkg clean find: /usr/src/modules: Aucun fichier ou répertoire de ce type Bon...facile ? Traduction : En gros, make-kpkg te dit que tu n'as pas de modules (autres que ceux propres du noyau) dans /usr/src/modules. Après, make-kpkg passe à la suite, comme un grand. Facile. A++ Nicolas PS : /usr/share/doc/kernel-package/README.modules, limpide.
Re: Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
Le Thu 13/12/2001, Nicolas Boos disait Le Thu, 13 Dec 2001 22:37:58 +0100 Erwan David [EMAIL PROTECTED] écrivait : [...] Par exemple (95% du temps) : make-kpkg clean make-kpkg --revision=1 kernel_package Trop dur. Mais, il me semble aussi que l'on a eu cette discussion il n'y a pas si longtemps déjà... ben déjà ça ne marche pas : bretagne:/usr/src/linux % make-kpkg clean find: /usr/src/modules: Aucun fichier ou répertoire de ce type Bon...facile ? Traduction : En gros, make-kpkg te dit que tu n'as pas de modules (autres que ceux propres du noyau) dans /usr/src/modules. Après, make-kpkg passe à la suite, comme un grand. ET pourquoi j'aurais des modules dans /usr/src/moduile ? si je patche le noyau je patche dans l'arbre, pas à côté... -- Erwan
Re: Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
Le Thu 13/12/2001, Nicolas Boos disait Le Thu, 13 Dec 2001 22:37:58 +0100 Erwan David [EMAIL PROTECTED] écrivait : [...] Par exemple (95% du temps) : make-kpkg clean make-kpkg --revision=1 kernel_package Trop dur. Mais, il me semble aussi que l'on a eu cette discussion il n'y a pas si longtemps déjà... ben déjà ça ne marche pas : bretagne:/usr/src/linux % make-kpkg clean find: /usr/src/modules: Aucun fichier ou répertoire de ce type Bon...facile ? Traduction : En gros, make-kpkg te dit que tu n'as pas de modules (autres que ceux propres du noyau) dans /usr/src/modules. Après, make-kpkg passe à la suite, comme un grand. Bon ben j'ai testé... Déjà t'avait pas dit qu'il fallait le configurer avant... ensuite ça se termine par : gpg: `Unknown Kernel Package Maintainer [EMAIL PROTECTED]' a été ignoré: la clé secrète n'est pas disponible gpg: [stdin]: clearsign failed: la clé secrète n'est pas disponible make: *** [stamp-buildpackage] Erreur 2 Bref ça marche pas... Alors entre ma méthode qui marche, et la tienne qui marche pas, j'ai choisi. -- Erwan
[LONG] [TRÈS LONG] Re: Noyau Debian [C'était : Re: [LONG] Re: comment demarrer fwm2]
Erwan David wrote: Le Thu 13/12/2001, Nicolas Boos disait Traduction : En gros, make-kpkg te dit que tu n'as pas de modules (autres que ceux propres du noyau) dans /usr/src/modules. Après, make-kpkg passe à la suite, comme un grand. PS : /usr/share/doc/kernel-package/README.modules, limpide. bretagne:~ % less usr/share/doc/kernel-package/README.modules usr/share/doc/kernel-package/README.modules: Aucun fichier ou répertoire de ce type Manque un / au début ... Ah mince, tu es peut-être en stable ... Pas de chance, le fichier n'existe que pour testing et unstable. Bah dans quelques mois, woody deviendra stable ... ;-) Je répond aussi à quelques autres courriels de Erwan David : ET pourquoi j'aurais des modules dans /usr/src/moduile ? si je patche le noyau je patche dans l'arbre, pas à côté... Parce que ce ne sont généralement pas tes propres patches qui vont à cet endroit, mais plutôt ceux de projets liés au développement du noyau (cela permet de garder le répertoire du noyau propre), mais pas inclus pour différentes raisons. Personnellement, j'ai nvidia-kernel-src, cdfs, lm-sensors, em8300, ftpfs et i2c (bon celui-ci est dans le noyau, mais cette version est censée être plus à jour). Et si un jour, je veux modifier mon noyau à la main, je ferai mes modifs directement dans les sources du noyau, à charge pour moi de faire attention quand je patcherai d'une version du noyau à une autre (de 2.4.16 en 2.4.17 par exemple) Ailleurs, il a également écrit : gpg: `Unknown Kernel Package Maintainer [EMAIL PROTECTED]' a été ignoré: la clé secrète n'est pas disponible gpg: [stdin]: clearsign failed: la clé secrète n'est pas disponible make: *** [stamp-buildpackage] Erreur 2 Bizarre, dans la documentation (AMA très bien faite, mais en anglais) (/usr/share/doc/kernel-package/README.gz), il n'est pas indiqué, dans les instructions rapides, de lancer un make-kpkg buildpackage. Peux-tu suivre les 6 étapes indiquées et nous dire si cela fonctionne ? (Il aurait également été judicieux de nous donner la commande à l'origine de l'erreur pour déterminer la cause exacte du problème) (cf. l'explication de cette erreur plus bas) Il a également évoqué la quasi-obligation d'utiliser des modules : En plus elle mforce un modèle de noyau : celui avec quasiment tou t en module. Je regrette sur lma machine je sais ce que j'utilise je n'ai donc quasiment aucun module. Ceci est inexact, cette option est configurée par le make config standard du kernel et peux parfaitement être désactivée (via l'option CONFIG_MODULES). make-kpkg se fiche qu'il y ait peu ou beaucoup de modules. Le seul problème éventuel se pose si le noyau est tros gros (en zImage ou en bzImage), mais la compilation standard du noyau a le même problème. Il a aussi parlé des mainteneurs scripts : C'est un mélange d'affirmations gratuites sur des avantages qui n'en sont pas (des tas de points que je sais parfaitement faire tout seul sans make-kpkg), ça mélange le noyau que tu fais toi même et le noyau que tu downloa des (les mainteneur scripts par exemple ça c'est un noyau que tu downloade précompilé pas un noyau que tu fais toi même). Si je ne me trompe pas, il ne s'agit pas de cela, mais bien de scripts installés dans le noyau compilé par make-kpkg : lors de l'installation du paquet, il te demande par exemple si tu veux exécuter lilo (ou autre), si tu veux déplacer ton répertoire de modules (au cas où le nom du répertoire est le même) et une autre question qui m'échappe actuellement. Il a enfin parlé de make-kpkg clean qui ne marche pas : ben déjà ça ne marche pas : bretagne:/usr/src/linux % make-kpkg clean find: /usr/src/modules: Aucun fichier ou répertoire de ce type Bizarre, chez moi, ça va au bout (unstable et testing) (en ayant délibérément renommé le répertoire /usr/src/modules) : [EMAIL PROTECTED]:/usr/src/linux$ make-kpkg clean find: /usr/src/modules: Aucun fichier ou répertoire de ce type find: /usr/src/modules: Aucun fichier ou répertoire de ce type make[1]: Entering directory `/usr/src/linux-2.4.16' [... pas mal de nettoyage] rm -f /usr/src/linux-2.4.16/scripts/mkdep-docbook rm -rf DBTOHTML_OUTPUT* make[3]: Leaving directory `/usr/src/linux-2.4.16/Documentation/DocBook' rm -f core `find . \( -not -type d \) -and \ \( -name '*.orig' -o -name '*.rej' -o -name '*~' \ -o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \ -o -name '.*.rej' -o -name '.SUMS' -o -size 0 \) -type f -print` TAGS tags make[2]: Leaving directory `/usr/src/linux-2.4.16' test ! -f config.precious || mv -f config.precious .config rm -rf debian/tmp-source debian/tmp-headers debian/tmp-image debian/tmp-doc test -f stamp-building || test -f debian/official || rm -rf debian make[1]: Leaving directory `/usr/src/linux-2.4.16' [EMAIL PROTECTED]:/usr/src/linux$ Après, c'est peut-être un bug de make-kpkg de stable ... Après tout, il a pas mal de bugs
[LONG] Re: comment demarrer fwm2
[Ma dernière intervention à ce sujet, je crois avoir résumé ma pensée. Après, goûts, couleurs, toussa...] Salut Nicolas, L'intérêt? Changer le gestionnaire de fenêtres choisit par défaut. On ne devrait passer que par un outil centralisateur pour ce genre de choses. La solution du Xsession est mauvaise parce-que qu'elle est spécifique. Spécifique ? C'est le terme que j'aurai employé à l'encontre d'une méthode ne s'appliquant qu'à une distrib, comme quoi... Dans une doc, quelle différence de complexité y a-t-il entre dire d'utiliser telle commande, ou de mettre une ligne dans un fichier ? Pour répondre à ton deuxième (en vulgarisant) : 1. Il faut connaître la ligne spécifique 2. Il faut connaître le fichier spécifique Pas évident de connaître les nombreuses spécificités ;-) Pour répondre au premier (en vulgarisant, aussi) : 1. Il faut connaître la commande spécifique 2. Il faut connaître les options spécifiques Pas évident de connaîtres les nombreuses spécificités ? ;) Bin si, dans les deux méthodes, le seul moyen est de lire la doc. Et la doc, que dit-elle ? a) man update-alternatives [...] ACTIONS --install lien gen chemin pri [--slave slien sgen schemin] ... Ajoute un groupe d'alternatives au système. gen est le nom générique du lien principal, lien est le nom de son lien symbolique, et chemin est l'alter native présentée pour le lien principal. [snip une quizaine de lignes expliquant comment bien se débrouiller avec tous ces liens] b) Mettez le chemin de votre window manager dans un fichier .xsession de votre répertoire personnel, éventuellement précédé de commandes que vous souhaitez lancer également. Cf /usr/share/doc/xfree86-common/examples/xsession pour un exemple de fichier xsession abondamment commenté. L'un est-il plus compliqué que l'autre ? Je ne le pense pas : les deux méthodes nécessitent de lire la doc, laquelle explique de manière simple comment arriver au résultat souhaité. Aucune, si ce n'est que la deuxième solution aura l'avantage de fonctionner sur d'autres Unices. ET ALORS? N'importe quoi. Dans ta logique, pourquoi s'emmerder à utiliser et profiter des outils Debian Je l'ai déjà dit. J'utilise avec plaisir les nombreux outils Debian qui me simplifient bien la vie (en particulier l'excellent système de paquets). Mais uniquement quand ils apportent réellement quelquechose par rapport à une méthode classique. puisque l'on peut aisément tout fait à la mano Pas du tout. « aisément », oui dans le cas qui nous concerne, puisqu'en une ligne à la syntaxe toute simple, c'est réglé. Je n'ai jamais généralisé à « tout ». Et je n'ai rien contre les front-ends. Par exemple pour ma connexion internet, je n'ai jamais mis les mains dans /etc/ppp/ : wvdialconf et c'était bon. Ou encore, j'ai été bien content d'avoir l'aide de l'interface pour exim qui m'a créé un fichier exim.conf que je n'aurais pas aimé avoir à créer « from scratch ». (si exim.conf est loin d'égaler la complexité d'un sendmail.cf, il est quand même plus ardu que xsession, non ?) _Mais_ * Qu'est-ce qui est reproché aux utilisateurs qui ne connaissent qu'une distribution comme Mandrake ? Tout simplement d'être totalement démunis dès que leurs interfaces DrakTruc rencontrent le moindre petit problème solvable facilement à la main. * As-tu toujours le choix d'utiliser Debian, quand tu n'es pas chez toi, sur des machines pour lesquelles tu n'es pas root ? (quand déjà tu as la chance de pouvoir utiliser un Unix) Pas moi, je suis partagé entre RedHat et Solaris. Et c'est _très_ agréable d'avoir un fichier standard, xsession, commun aux deux, et de ne pas avoir à rechercher quelle est la super commande conviviale qui permet de changer de gestionnaire de fenêtres. (certains disent, comme un goret, mais c'est une position extrémiste je trouve). Oui, pour toutes les raisons précédentes. [noyau à la sauce Debian] C'est bien une réflexion d'utilisateur confirmé ça :-^ . La méthode classique est très rebutante pour le novice, pour ne pas dire compliquée. Différence de perception, encore une fois (si on parle bien de la même chose : compilation du noyau et non simple installation via apt). Les principales étapes sont partagées par les deux méthodes. De plus, tu as probablement choisi le plus mauvais exemple ; voir aussi : -- /usr/share/doc/kernel-package/Rationale.gz Lu. Mais pas convaincu. (attention, je reprécise : dans mon cas particulier d'admin d'une unique machine. Je trouve ça très intéressant dans d'autres situations) J'avais déjà des noyaux compilés classiquement quand je me suis posé la question du kernel-package. J'ai pesé le pour et le contre de changer de méthode, et ça n'a pas été déterminant. Paresse, inertie, certainement ! ;) Écris vite à Manoj Srivastava :-) Non, mon intention n'est pas d'imposer mon point de vue. C'est même
Re: [LONG] Re: comment demarrer fwm2
En réponse à Cedric Duval [EMAIL PROTECTED]: Salut, [...] L'intérêt? Changer le gestionnaire de fenêtres choisit par défaut. On ne devrait passer que par un outil centralisateur pour ce genre de choses. La solution du Xsession est mauvaise parce-que qu'elle est spécifique. Spécifique ? C'est le terme que j'aurai employé à l'encontre d'une méthode ne s'appliquant qu'à une distrib, comme quoi... Tout à fait. Mais, a priori ici on utilise Debian, l'outil est commun. Ce que je voulais dire que le Xsession a un champ de couverture propre, ce que donc je nommais spécifique. [pleins de choses, très bien] L'un est-il plus compliqué que l'autre ? Je ne le pense pas : les deux méthodes nécessitent de lire la doc, laquelle explique de manière simple comment arriver au résultat souhaité. Attention! Je n'ai pas dis que l'un était plus compliqué que l'autre (et vice-versa), mais la manière de faire du update-alternatives ne nécessite pas de réapprentissage pour un autre objet (voir aussi mon exemple du XYZ). Aussi, on peut difficilement savoir que c'est le fichier Xsession qui est à modifier pour changer de WM par défaut ; avec update-alternatives, on devine/retrouve très facilement ce qu'il est nécessaire de faire (on regarde dans /etc/alternatives par exemple). [références à Mandrake, RedHat, Solaris] Tu t'égards Cédric. Ce n'est pas notre problème si Debian n'est pas universellement déployée. Ici, on _doit_ présenter la façon de faire Debian, qui est AMHA généralement la plus _juste_ (pour toutes les raisons déjà évoquées). [noyau à la sauce Debian] [pareil] -- /usr/share/doc/kernel-package/Rationale.gz Lu. Mais pas convaincu. [...] Pourquoi? (étayes STP) Paresse, inertie, certainement ! ;) Inertie, je comprends alors... ;-) Non, mon intention n'est pas d'imposer mon point de vue. C'est même l'inverse : si la discussion a débuté, c'est justement parceque je trouvais que Christian en faisait un peu trop en refusant tout ce qui n'était pas _La_ Debian Way la plus pure. Mais la pensée de Christian va dans le bon sens. Les Unices sont trop prévus pour les admins (j'entends là, utilisateurs avertis) ; il est grand temps qu'ils soit prévus un peu plus pour les utilisateurs lambdas. Debian va dans ce sens (de plus en plus je trouve). YADONKPLUKA modifier le update-alternatives... ;-) ^^^ Tu t'y colles donc ? ;) Pourquoi pas (après Janvier, pas avant, si vous voyez ce que je veux dire..). Mais avant, il faut que l'on discute pour voir comment cela doit se faire. A++ Nicolas
Re: [LONG] Re: comment demarrer fwm2
bonjour, j'ai pas suivi tout le fil de discussion, mais, sans rentrer dans des considérations pointues sur la méthode update-alternatives, pour les gestionnaires de fenêtres, il y a le paquet 'wmanager' que je trouve bien pratique ! j'ai gdm --- GNOME (direct) | -- KDE (direct) | -- Debian (passe la main à wmanager) | -- Afterstep | -- WindowMaker | -- etc. (tout ce qui est dans le .wmanagerrc) ici, il y a 23 gestionnaires de fenêtres différents (!) c'est une machine de démo... je n'utilise quasiment qu'afterstep. a+ -- Stéphanie, Fabrice et Fiona -o) [EMAIL PROTECTED]/\\ [EMAIL PROTECTED] _\_V
Re: [LONG] Re: comment demarrer fwm2
J'avais pourtant dit qu'on ne m'y reprendrait plus. :-/ Je ne suis pas certain que notre mini-débat passionne les foules, donc suivi en privé si tu veux bien. Attention! Je n'ai pas dis que l'un était plus compliqué que l'autre (et vice-versa), mais la manière de faire du update-alternatives ne nécessite pas de réapprentissage pour un autre objet (voir aussi mon exemple du XYZ). Aussi, on peut difficilement savoir que c'est le fichier Xsession qui est à modifier pour changer de WM par défaut ; avec update-alternatives, on devine/retrouve très facilement ce qu'il est nécessaire de faire (on regarde dans /etc/alternatives par exemple). Pour le débutant ça ne fera pas de différence. update-alternatives ne s'invente pas plus que xsession. Il découvrira l'une ou l'autre des manières de procéder dans une doc. Peut-être sur le DPT :) ou ailleurs. Osons même l'impensable : sur une liste de discussion ! [références à Mandrake, RedHat, Solaris] Tu t'égards Cédric. Ce n'est pas notre problème si Debian n'est pas universellement déployée. Justement, si. Ton point de vue est que update-alternatives est mieux car c'est un outil qui a un champ d'application plus vaste, et donc pour peu que l'utilisateur s'informe à son sujet, il pourra le réutiliser sans réapprentissage pour autre chose. C'est effectivement très bien : grâce à cette commande, j'ai par exemple vi == vim par défaut pour tous mes utilisateurs, ce qui au bas mot doit avoisiner les 2 utilisateurs sur cette machine, root et moi ! Et encore, mon root est schizophrène :) Mon point de vue est que xsession vaut bien la méthode Debian [1] car * elle est d'égale simplicité * elle peut servir ailleurs Tu me parles de réutilisabilité, du bienfait d'éviter à l'utilisateur le réapprentissage de méthodes... Tiens, ça ne s'appliquerait pas non plus à mes arguments ? ;) La seule différence est que tu fais comme s'il n'y avais rien en dehors de Debian. Malheureusement (ou heureusement, la diversité a aussi du bon) ça n'est pas vrai, et combien de personnes ici sont obligées d'utiliser d'autres Unices à leur travail ? 1. En fait la comparaison s'effectue sur une hypothétique méthode Debian qui ferait l'équivalent d'xsession. Comme à ce jour, elle n'existe pas, tout ceci est un peu futile. En plus, comme l'a dit Jérome, c'est un faux problème. Ici, on _doit_ présenter la façon de faire Debian, qui est AMHA généralement la plus _juste_ (pour toutes les raisons déjà évoquées). C'est ce « on _doit_ » qui me gène. Vraiment. Je sais bien que la liste concerne Debian. Cela interdit-il de répondre à une question par une méthode plus générale ? Ne sommes nous pas, en plus d'être debianistes, tous des linuxiens (oups, y a-t-il des hurdistes dans la salle ?), sous-ensemble des unixiens de la catégorie des mammifères vertébrés ? Me suggères-tu de me désabonner car je risque de mettre le débutant sur la mauvaise voie ? ;) Non, je ne pense pas que l'auteur de la question soit perdant à recevoir des réponses variées. Il fera le tri comme bon lui semble ensuite. Et il se trouvera toujours quelqu'un pour corriger s'il existe une meilleure alternative. TIMTOWTDI -- /usr/share/doc/kernel-package/Rationale.gz Lu. Mais pas convaincu. [...] Pourquoi? (étayes STP) Paresse, inertie, certainement ! ;) La conséquence de ceci est que si j'ai connaissance d'une méthode susceptible de me simplifier la vie, je l'adopterai sans hésiter et sans remords, comme je l'ai déjà fait pour tant d'utilitaires Debian... Inertie, je comprends alors... ;-) Oualà. J'ai déjà tout dit. Tout n'est qu'une question de balance. J'ai bien lu tous les arguments, et répondu à la question: y a-t-il des avantages suffisamment déterminants qui vaillent que je change de méthode ? Non, mon intention n'est pas d'imposer mon point de vue. C'est même l'inverse : si la discussion a débuté, c'est justement parceque je trouvais que Christian en faisait un peu trop en refusant tout ce qui n'était pas _La_ Debian Way la plus pure. Mais la pensée de Christian va dans le bon sens. Les Unices sont trop prévus pour les admins (j'entends là, utilisateurs avertis) ; Il faut bien avouer que la grande force de Debian réside pour une bonne part dans sa facilité d'administration. il est grand temps qu'ils soit prévus un peu plus pour les utilisateurs lambdas. Debian va dans ce sens (de plus en plus je trouve). Oui. Finalement, sur le fond on est plutôt en accord, non ? :) fu2 poster. -- Cédric
Re: [LONG] Re: comment demarrer fwm2
Le Wed 12/12/2001, [EMAIL PROTECTED] disait En réponse à Cedric Duval [EMAIL PROTECTED]: [noyau à la sauce Debian] [pareil] -- /usr/share/doc/kernel-package/Rationale.gz Lu. Mais pas convaincu. [...] Pourquoi? (étayes STP) C'est un mélange d'affirmations gratuites sur des avantages qui n'en sont pas (des tas de points que je sais parfaitement faire tout seul sans make-kpkg), ça mélange le noyau que tu fais toi même et le noyau que tu downloa des (les mainteneur scripts par exemple ça c'est un noyau que tu downloade précompilé pas un noyau que tu fais toi même). En plus elle mforce un modèle de noyau : celui avec quasiment tou t en module. Je regrette sur lma machine je sais ce que j'utilise je n'ai donc quasiment aucun module. Par ailleurs je trouve la doc de makke-kpkg absconse et je n'ai jamais réussi à comprendre comment l'utiliser. -- Erwan
[LONG] Re: comment demarrer fwm2
Le Tue, 11 Dec 2001 11:19:53 +0100 Cedric Duval [EMAIL PROTECTED] écrivait : Salut, [...] Le problème des alternatives, c'est qu'elles s'appliquent a tout le monde. [...] _Tout_ le problème est là. Il faudrait que chaque utilisateur puisse définir ses propres alternatives (Bon. Dit comme cela, c'est peut-être faire du simplisme...). C'est utile pour donner aux utilisateurs un window manager par défaut acceptable. Ensuite, il est bon qu'ils aient la liberté d'outrepasser le choix de l'administrateur. Tout à fait. Je ne sais pas si le sujet a été abordé sur les listes des developpeurs Debian ? Mais qu'y a-t-il à aborder à ce sujet ? Le fait que les utilisateurs ne disposent pas de programme permettant de changer leur window manager ? Quel intérêt ? L'intérêt? Changer le gestionnaire de fenêtres choisit par défaut. On ne devrait passer que par un outil centralisateur pour ce genre de choses. La solution du Xsession est mauvaise parce-que qu'elle est spécifique. Il vaut mieux utiliser l'outil centralisateur A pour choisir le X, Y et Z par défaut. Pas question d'étudier U pour choisir X, V pour Y et W pour Z. C'est pourtant simple... Dans une doc, quelle différence de complexité y a-t-il entre dire d'utiliser telle commande, ou de mettre une ligne dans un fichier ? Pour répondre à ton deuxième (en vulgarisant) : 1. Il faut connaître la ligne spécifique 2. Il faut connaître le fichier spécifique Pas évident de connaître les nombreuses spécificités ;-) Aucune, si ce n'est que la deuxième solution aura l'avantage de fonctionner sur d'autres Unices. ET ALORS? N'importe quoi. Dans ta logique, pourquoi s'emmerder à utiliser et profiter des outils Debian puisque l'on peut aisément tout fait à la mano (certains disent, comme un goret, mais c'est une position extrémiste je trouve). De plus, une solution passant par un utilitaire Debian aurait le défaut de ne présenter une alternative que pour les WM installés par l'intermédiaire des paquets, pas le fvwm2 que l'utilisateur a compilé dans son répertoire perso parceque l'administrateur ne juge pas utile de l'installer. Si l'utilisateur pouvait définir ses propres alternatives, suffirait un simple : update-alternatives --install /home/utilisateur/bin/wm x-window-manager ... (je sais, je vais bientôt mettre Paris en bouteille...). Utiliser des front-end, c'est Bien, mais pas pour tout et n'importe quoi. C'est utile quand le format interne de la donnée manipulée peut varier d'une version à l'autre (cas des paquets). Ou pour faciliter le déployement sur un réseau (les noyaux à la sauce Debian par exemple. Qui par contre n'apportent rien à la méthode classique dans le cas d'une machine personnelle unique). C'est bien une réflexion d'utilisateur confirmé ça :-^ . La méthode classique est très rebutante pour le novice, pour ne pas dire compliquée. De plus, tu as probablement choisi le plus mauvais exemple ; voir aussi : -- /usr/share/doc/kernel-package/Rationale.gz Écris vite à Manoj Srivastava :-) [...] Certainement pas pour une opération qui nécessite l'ajout d'une ligne dans un fichier ! En reprenant ce que je disais tout à l'heure, on peut facilement répondre qu'une fois la méthode du update-alternatives acquise (et qui a l'avantage de s'appliquer à bien d'autres champs que celui du gestionnaire de fenêtres), il est bien plus aisé d'arriver à ses fins, que de savoir qu'il faut modifier tel ou tel fichier et, de plus, de savoir quoi modifier en son sein. YADONKPLUKA modifier le update-alternatives... ;-) A++ Nicolas
