[Varia] Petites questions non-essentielles (résolu)

[Lunatic]

Bonjour à tous,

Je commence mal puisque, pour mon premier message, je ne respecte pas les règles et pose plusieurs questions. Mais celles-ci me semblant « petites » je m'autorise cette entorse...

1/ Comment prononce-t-on « Arch » ? Ark ? Artch ? Arche ?

2/ J'ai lu (avec grand plaisir, tant il est bien rédigé) le wiki et notamment la page sur rc.conf, et aimerais demander quelques précisions :
a/ je comprends bien l'intérêt de lancer en tâche de fond le service network, par exemple. Mais qu'elle est l'utilité de procéder ainsi pour, par exemple, alsa ou gdm ? Je pourrais inverser la question : quelle est l'utilité (le risque/l'avantage/l'inconvénient) de lancer de tels services en « avant-plan ». Accélère-t-on le démarrage en lançant le plus possible de services en tâche de fond .
b/ le tableau du wiki présente les services exécutables - ou pas - en tâche de fond. Mais pour des services non listés, comment est-on censé savoir ?

Voilà, pour le moment, c'est tout. Je file me présenter.

Merci d'avance, et bonne soirée !

[Martin Matin]

Salut à toi !

Pour ma part je prononce arch comme dans "l'arche de Noé".

Sinon pour l'intérêt de lancer lesdits services en tâches de fond, si tu entend mettre un "@" devant leur nom dans le rc.conf à la section daemons, cela permet de ne pas attendre que le service soit complètement démarré avant d'en lancer un autre.

On peut par exemple lancer gdm avant qu'alsa ait fini de démarrer: tu ne l'utilisera pas ave gdm, et une fois loggé il aura eu le temps de se lancer.

Je crois que c'est ça, qu'on me corrige si je me trompe =D

[Lunatic]

Bonsoir,

Merci pour ta réponse ; en fait c'est bien ce que j'avais compris. Mais du coup, quel est l'intérêt à ne pas mettre le @ ? Entre attendre et ne pas attendre que le service soit démarré, le choix est vite fait

Mais j'imagine qu'il y a là une subtilité qui m'échappe.

[Martin Matin]

Certains services reposent sur d'autres pour se lancer, et dans ce cas il est impératif de les attendre ^^

[tuxce]

salut
par exemple, dbus est nécessaire pour lancer le bluetooth, ou par exemple wicd etc...

la plupart du temps, c'est indiqué sur le wiki

[Lunatic]

Merci encore pour vos réponses ; j'avais bien compris que certains services devaient être lancés pour que d'autres le soient à leur tour, et c'est bien pour cela que le wiki indique bien qu'on ne peut pas lancer dbus ou hal, par exemple, en arrière plan.

Je vais donc poser ma question autrement : lorsqu'il est possible de lancer un service en arrière plan (alsa, sshd, cups, etc.), n'a-t-on pas toujours intérêt à le faire ?

[Cactus]

bah si, justement !

[farvardin]

C'est vrai que c'est bizarre quand même, parce que sur le site d'archlinux, souvent les références sont faites sans indiquer l'arobase, par exemple ici pour le network :
http://wiki.archlinux.org/index.php/Setting_up_Samba

D'ailleurs, samba n'est pas indiqué sur le wiki francophone. Je présume qu'on peut le lancer en tâche de fond, et y a-t-il une préférence pour l'endroit où le lancer ? Juste après network c'est bon ? Et si tout est en tâche de fond, n'y a-t-il pas risque que samba commence avant que network soit prêt ?

[Cactus]

si tu ne mets pas d'arobase à network, les services suivants attendront qu'il ait fini de se charger, donc c'est bon !

(il va falloir prendre confiance en toi, tu comprends très bien dès le début, mais tu as toujours peur de mal comprendre... et pourtant, tout est simple ! ).

[tuxce]

Je vais donc poser ma question autrement : lorsqu'il est possible de lancer un service en arrière plan (alsa, sshd, cups, etc.), n'a-t-on pas toujours intérêt à le faire ?

en gros, tu te dis pourquoi ne pas les lancer en tache de fond automatiquement?

pour dbus + hal par exemple, ils sont nécessaires (ou hautement recommandés) avant gnome car ce dernier en a besoin dès le démarrage, mais pour le couple openbox/pcmanfm par exemple, ils sont pas nécessaire, openbox ne les utilise pas et pcmanfm en a besoin ponctuellement, on peut donc les lancer en tache de fond pour ce couple, ça répond à la question ?
(c'est un exemple parmi d'autres)

[Lunatic]

en gros, tu te dis pourquoi ne pas les lancer en tache de fond automatiquement?

pour dbus + hal par exemple, ils sont nécessaires (ou hautement recommandés) avant gnome car ce dernier en a besoin dès le démarrage, mais pour le couple openbox/pcmanfm par exemple, ils sont pas nécessaire, openbox ne les utilise pas et pcmanfm en a besoin ponctuellement, on peut donc les lancer en tache de fond pour ce couple, ça répond à la question ? Smile
(c'est un exemple parmi d'autres)

Voilà, c'est une autre façon de poser ma question. Donc ok pour dbus et HAL.

Mais est-ce que tous les services sont soumis à ce genre d'exigence ou y'en a-t-il (je songe à alsa, par exemple) qui peuvent toujours être lancés en arrière plan ?

Je poursuis avec mes questions de noob :
- ce que tu dis sur la dépendance gnome/hal+dbus et l'indépendance openbox/hal+dbus est très intéressant. Mais comment est-on censé savoir cela ? Par l'expérience (je veux dire, par le tâtonnement) ? Ou y'a-t-il un endroit qui indique clairement ce genre de choses ? (le man d'openbox ?)

Bon en tout cas j'ai bien la réponse à ma question : quand c'est possible, il est profitable de lancer un service en arrière-plan. Merci à vous, je me coucherai tranquille et un peu moins sot ce soir

[tuxce]

Mais est-ce que tous les services sont soumis à ce genre d'exigence ou y'en a-t-il (je songe à alsa, par exemple) qui peuvent toujours être lancés en arrière plan ?

la liste des services étant en théorie infinie, on va pas passer en revue un/un, le principe est simple, si un service a besoin d'un autre à son démarrage, lancer le 1er en tache de fond n'est pas une bonne idée.

Maintenant pour ce qui est de le savoir à l'avance, je te l'ai indiqué avant, le wiki est assez clair la dessus, sinon, il y a le forum et oui, si la doc (pas forcément le man) du soft est bien faite, c'est indiqué dessus.

[Lunatic]

Mais est-ce que tous les services sont soumis à ce genre d'exigence ou y'en a-t-il (je songe à alsa, par exemple) qui peuvent toujours être lancés en arrière plan ?

la liste des services étant en théorie infinie (...)

Certes.

Maintenant pour ce qui est de le savoir à l'avance, je te l'ai indiqué avant, le wiki est assez clair la dessus, sinon, il y a le forum et oui, si la doc (pas forcément le man) du soft est bien faite, c'est indiqué dessus.

Si je posais la question, c'était simplement parce que, dans l'absolu, je trouve ça un peu étrange d'être tributaire d'un wiki ou d'un forum ; je cherchais donc à savoir quel était « l'endroit » où trouver « officiellement » ce genre d'info. Merci pour la réponse, donc.

[Cactus]

Pour info, voici mon rc.conf :

Code : Tout sélectionner

DAEMONS=(syslog-ng hwd hal @wicd @firestarter @cups @netfs @crond @noip)

NB : wicd est une alternative à network (et si tu as un wifi et/ou un PC nomade, il peut s'avérer très pratique !)

[Lunatic]

Merci !
Pour wicd, c'est ce que j'utilise déjà sur mon eeePC

[gyo]

Je poursuis avec mes questions de noob :
- ce que tu dis sur la dépendance gnome/hal+dbus et l'indépendance openbox/hal+dbus est très intéressant. Mais comment est-on censé savoir cela ? Par l'expérience (je veux dire, par le tâtonnement) ? Ou y'a-t-il un endroit qui indique clairement ce genre de choses ? (le man d'openbox ?)

Hal n’est d’aucune utilité pour openbox, ce dernier étant uniquement un gestionnaire de fenêtre. tuxce parlait de pcmanfm qui est en gestionnaire de fichier léger qui se marie bien avec des WM léger comme openbox/fluxbox/awesome/wmii/etc. Et ce gestionnaire de fichier utilise (ou peut utiliser ?) Hal pour ce qui est le montage des périphériques amovibles. Dans ce cas, c’est plutôt un man sur le gestionnaire de fichier ou la doc du site du projet, ou que sais-je encore…

P-S : ouais, enfin je viens de me rendre compte que je redis d’une autre manière ce que tuxce a expliqué

[marc[i1]]

P-S : ouais, enfin je viens de me rendre compte que je redis d’une autre manière ce que tuxce a expliqué

La reformulation est la base de la pédagogie