et bien, merci, je viens d'apprendre quelque chose. :)
J'ignorai que devfsd pouvais rendre ce genre de service (pour moi, devfs ne servait "qu'à" organiser l'arborescence sous /dev d'une façon plus "explicite").
Pour ceux qui sont interressés, la doc de devfs/devfsd : http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html(...)
mea culpa : propre était un abus de language. j'aurais du dire de base ou brut de distrib ou encore sans tripatouillages gruïk ;)
Si CONFIG_DEVFS_FS=y (support devfs) dans la config du noyau debian, par contre CONFIG_DEVFS_MOUNT (prise en compte de devfs dès le boot sans modification de lilo.conf) n'est pas positionné par défaut et le package "devfsd" a une priorité "optional" seulement (logique puique les deux sont liés). On ne peut pas dire que debian fasse le forcing pour imposer ce mode de fonctionnement. A terme, utiliser devfs par defaut dès l'installation offrira des avantages certains mais ce n'est pas encore le cas (loin s'en faut).
Enfin, je ne sais pas si l'un est mieux que l'autre pour cette tache mais kerneld est déjà censé charger les modules à la demande, non ? je ne veux pas lancer un debat à la con mais tu sembles dire que la methode "devfs" est plus "propre". En l'état actuel de la distrib (stable) et du point de vue de l'utilisateur lambda, quels sont les arguments pour une solution ou une autre ?
Ca m'interresse vraiment parce que la gestion des modules du noyau (et plus generalement la gestion des periphériques) est une question récurrente de la part des nouveaux venus et que je trouvais la "solution" modconf sous debian des plus satisfaisante (ie ultra simple si on connait son materiel et efficace) jusqu'à aujourd'hui tandis que devfs était (comme initrd d'ailleurs) une "feature" interressante mais absolument pas indispensable dans l'immediat.
c'est vrai ça ! pourquoi faire simple quand on peut faire compliquer !?
blague a part, debian est une distrib evoluée. ce n'est pas LFS...
sous une debian propre, la gestion des modules se fait avec modconf et seulement modconf (bon d'accord dans seulement 99,99% des cas).
pour installer des modules supplémentaires a ceux de la distrib, apt.
pour alsa : apt-get install alsa-modules-ta_saveur_de_noyo
tout est expliqué en detail (trop de details ?) dans la page que tu donnes en lien.
tu trouveras beaucoup de réponses à ce genre de questions en consultant les archives de la list debian-user-french et surtout sa FAQ : http://savannah.nongnu.org/download/debfr-faq/(...)
C'est LA source d'information a consulter en priorité pour les debianistes ;)
c'est un peu le mélange des genres, je suis bien d'accord, mais la news concerne surtout l'arrivée d'un nouveau constructeur dans le "camp" de ceux qui fournissent les specs et meme des drivers pour leur matériel (si j'ai j'interprete bien la pensee de l'auteur :)).
ceci dit, est-ce si exceptionnel que l'on doive le signaler pour chacun d'entre eux dans une news ?
peut-etre... aux moderos d'en decider apres tout.
cf. http://fontconfig.org/~keithp/teleconference/telecon-2003-04-10.txt(...)
(seconf lien de la news)
le "brainstorming" version j'en ai rien a foutre, j'ai des questions plus importantes sur le gril.
pour ceux qui ont la flemme ou ne causent pas l'anglais : c'est temporaire. l'objectif etait d'avoir une existance et de permettre a d'autres de trouver un nom au projet en offrant des outils pour demarrer.
il ne faut pas aller plus vite que la musique.
les newbies utilisent une distrib qui a installe un "environnement par defaut". donc ils prennent ce qu'on leur donne et la question ne se pose pas vraiment.
Par contre, j'attend avec impatience les reactions (ie prises de position) des differentes distributions et autres "acteurs industriels".
Apparemment, ce fork n'etait désiré par personne et c'est en desespoir de cause qu'il a eu lieu.
AMHA, il est encore bien tot pour percevoir toutes les implications que cela va avoir.
# Re: Le projet BOINC est suspendu
Posté par Ange Bara . En réponse à la dépêche Le projet BOINC est suspendu. Évalué à 10.
[^] # Re: Hors sujet
Posté par Ange Bara . En réponse à la dépêche IBM/Linux, maître du stockage. Évalué à 10.
kernel traffic n°212 : http://www.kerneltraffic.org/kernel-traffic/kt20030406_212.html(...)
Ne me demandez à quoi ça sert, je ne sais pas :).
[^] # Re: une méthode pour debian
Posté par Ange Bara . En réponse à la dépêche Pilotes « Open Source » chez Digigram. Évalué à 4.
J'ignorai que devfsd pouvais rendre ce genre de service (pour moi, devfs ne servait "qu'à" organiser l'arborescence sous /dev d'une façon plus "explicite").
Pour ceux qui sont interressés, la doc de devfs/devfsd : http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html(...)
mea culpa : propre était un abus de language. j'aurais du dire de base ou brut de distrib ou encore sans tripatouillages gruïk ;)
Si CONFIG_DEVFS_FS=y (support devfs) dans la config du noyau debian, par contre CONFIG_DEVFS_MOUNT (prise en compte de devfs dès le boot sans modification de lilo.conf) n'est pas positionné par défaut et le package "devfsd" a une priorité "optional" seulement (logique puique les deux sont liés). On ne peut pas dire que debian fasse le forcing pour imposer ce mode de fonctionnement. A terme, utiliser devfs par defaut dès l'installation offrira des avantages certains mais ce n'est pas encore le cas (loin s'en faut).
Enfin, je ne sais pas si l'un est mieux que l'autre pour cette tache mais kerneld est déjà censé charger les modules à la demande, non ? je ne veux pas lancer un debat à la con mais tu sembles dire que la methode "devfs" est plus "propre". En l'état actuel de la distrib (stable) et du point de vue de l'utilisateur lambda, quels sont les arguments pour une solution ou une autre ?
Ca m'interresse vraiment parce que la gestion des modules du noyau (et plus generalement la gestion des periphériques) est une question récurrente de la part des nouveaux venus et que je trouvais la "solution" modconf sous debian des plus satisfaisante (ie ultra simple si on connait son materiel et efficace) jusqu'à aujourd'hui tandis que devfs était (comme initrd d'ailleurs) une "feature" interressante mais absolument pas indispensable dans l'immediat.
[^] # Re: une méthode pour debian
Posté par Ange Bara . En réponse à la dépêche Pilotes « Open Source » chez Digigram. Évalué à 10.
blague a part, debian est une distrib evoluée. ce n'est pas LFS...
sous une debian propre, la gestion des modules se fait avec modconf et seulement modconf (bon d'accord dans seulement 99,99% des cas).
pour installer des modules supplémentaires a ceux de la distrib, apt.
pour alsa : apt-get install alsa-modules-ta_saveur_de_noyo
tout est expliqué en detail (trop de details ?) dans la page que tu donnes en lien.
tu trouveras beaucoup de réponses à ce genre de questions en consultant les archives de la list debian-user-french et surtout sa FAQ : http://savannah.nongnu.org/download/debfr-faq/(...)
C'est LA source d'information a consulter en priorité pour les debianistes ;)
[^] # Re: Pilotes « Open Source » chez Digigram
Posté par Ange Bara . En réponse à la dépêche Pilotes « Open Source » chez Digigram. Évalué à 8.
ceci dit, est-ce si exceptionnel que l'on doive le signaler pour chacun d'entre eux dans une news ?
peut-etre... aux moderos d'en decider apres tout.
[^] # Re: Fork d'XFree86
Posté par Ange Bara . En réponse à la dépêche Fork d'XFree86. Évalué à 5.
(seconf lien de la news)
le "brainstorming" version j'en ai rien a foutre, j'ai des questions plus importantes sur le gril.
pour ceux qui ont la flemme ou ne causent pas l'anglais : c'est temporaire. l'objectif etait d'avoir une existance et de permettre a d'autres de trouver un nom au projet en offrant des outils pour demarrer.
il ne faut pas aller plus vite que la musique.
[^] # Re: Fork d'XFree86
Posté par Ange Bara . En réponse à la dépêche Fork d'XFree86. Évalué à 10.
Par contre, j'attend avec impatience les reactions (ie prises de position) des differentes distributions et autres "acteurs industriels".
Apparemment, ce fork n'etait désiré par personne et c'est en desespoir de cause qu'il a eu lieu.
AMHA, il est encore bien tot pour percevoir toutes les implications que cela va avoir.