[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

C'est AMHA une croisade qui n'a pas lieu d'être.


> YADONKPLUKA modifier le "update-alternatives"... ;-)
  ^^^^^^^^^^^
Tu t'y colles donc ?  ;)


Bon, je résume :
[OUI] (mille fois oui !) à l'utilisation de commandes spécifiques quand
      elles apportent quelquechose de plus que la méthode classique, en
      la simplifiant par exemple.
[NON], quand l'avantage obtenu n'est pas déterminant par rapport à une
      méthode qui a l'avantage de fonctionner partout.

-- 
Cédric, qui adore sa Debian  :))



Reply to: