007 a écrit 2187 commentaires

OK, j'ai vu le problème.
J'avais [fr-fr] et il faut [fr]. Petit bug du site.

Sauf qu'actuellement ça ne marche pas. Firefox 0.10PR .
Mais ça a déjà marché :-)

> c'est parce que FAM utilise dnotify

fam n'utilise pas dnotify. C'est gamin qui le fait (+ l'ancienne méthode avec une boucle quand c'est nécessaire).

> car au niveau messagerie cela ne fonctionne pas encore terrible sour mon linux (fedora core 2)

T'as quoi comme problème ?

> Si quelqu'un a réussi cet exploit ça m'interesse :)

Je l'ai fait, il y a longtemps. Ça marche. Rien d'excèptionnel, faut lire la doc de vmware.

Ça doit être fait avec ça :
http://www.redhat.com/software/rha/appserver/(...)

Je ne sais plus où est le site de développement.

Voilà ici pour Fedora (elle fait ça automatiquement mais tu peux aussi le faire à la main).

Pour la carte snd_via8xx et snd_ens1371.
snd_ens1371 est la carte par défaut.

/etc/modprobe.conf :
alias snd-card-0 snd-ens1371
options snd-card-0 index=0
options snd-ens1371 index=0
remove snd-ens1371 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-ens1371
alias snd-card-1 snd-via82xx
options snd-card-1 index=1
options snd-via82xx index=1
remove snd-via82xx { /usr/sbin/alsactl store 1 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-via82xx

Si je n'ai pas ça, ens1371 n'est pas la carte par défaut (carte 0).

Si le driver qui va bien n'est pas chargé par Ubuntu, charge le à la main.
L'autre solution est d'utiliser /etc/asound.conf. Ça ne marche que pour les applis alsa.
asound.conf :
pcm.!default { type hw card 1 }
ctl.!default { type hw card 1 }

La seconde carte est utilisée par défaut (pour les applis alsa).

Vu la qualité du document, voilà un enregistrement qui n'est pas volé.

Ce document c'est carrément de balle.
Enormément de boulot.
C'est aussi un historique passionnant du logiciel libre.
UN MUST !

La première page ! La première page ! La première page !

Y a un truc Debian en première page. Ce truc (soit disant important) a été classé comme le onzième évènement de la semaine du dernier "Debian Weekly News" :
http://lwn.net/Articles/108283/(...)

Franchement, vous déconnez complètement.

PS : le document est libre.
PS2 : j'ai parcuru rapidement le premier tier. Je vais le lire en entier et attentivement.

Il y a plein de distributions qui n'installent que KDE et on en fait pas un fromage.

> Aux dernières nouvelles, il y a des patches de sécurité pour stable et unstable.

http://www.debian.org/devel/testing(...)

An important thing to note, both for regular users and the developers of testing, is that security updates for testing are not managed by the security team.

> Fedora trouve plus mieux d'utiliser kudzu...

kudzu c'est la détection de _nouveau_ matériel, l'enregistrement dans une base et la configuration de nouveau matériel (via /etc/modprobe.conf etc).
kudzu ne fait rien si le matériel est déjà connu dans sa base. Notes aussi que kudzu ne fait _rien_ pour le matériel hotplug.

> dpkg -S /etc/init.d/hotplug
> hotplug: /etc/init.d/hotplug

Effectivement, c'est aussi dans les fichiers upstream de hotplug . Ce fichier n'est pas utilisé (ni installé) par Fedora.
Ce qui fait la détection sous Fedora est kmodule. kmodule est dans initscripts. kmodule a été introduit dans FC3 à cause de udev (chargement des modules automatiques sur utilisation d'un fichier spécial n'est pas dispo puisque le fichier spécial n'est pas là tant que le driver n'est pas chargé).

Mais regardes bien /etc/init.d/hotplug (et /etc/hotplug/*rc) et vois comme /sbin/hotplug (généralement appelé depuis le noyau) et qui est le *coeur* d'hotplug ne fait rien pour la détection matériel !

J'ai regardé /etc/init.d/hotplug et c'est .... mouaif....
Maintenant je sais pourquoi Sarge me chargait plein de modules qui me servaient à rien. /etc/hotplug/*.rc n'est jamais utilisé par Fedora. À tord ou à raison ? Actuellement, j'en sais rien.

Pour Fedora il y a deux phases.
La détection faite par kmodule. Exemple :
# kmodule
NETWORK unicorn_pci_atm
AUDIO snd-via82xx
AUDIO snd-ens1371
CAPTURE bttv

Attention, kmodule ne charge _aucun_ module.

"modprobe -c" donnes d'autres infos (c-à-d modules à charger) pour du matériel non détectable par kmodule mais détecté et configuré par kudzu.

Jusque là, aucun modules n'est chargé.
Une fois que la liste des drivers nécessaires pour le hardware est connue, on passe à la phase 2 : les modules sont chargés par un simple "modprobe {modules}". C'est tout.
Au chargement des modules, hotplug sera appelé, etc...
Avec Fedora /sbin/hotplug est uniquement appelé depuis le noyau et est utilisé pour le branchement à chaud ou la "découverte" à chaud (par un driver) du matériel. C'est clean. D'ailleur il n'y a jamais eu de /etc/module pour charger des modules. Si tu fais "ifup ppp0", l'environnement doit être correctement configurer pour charger automatiquement les modules ou ifup doit le faire lui-même. C'est la philosophie.

> C'est bien, Debian est en avance sur RedHat

Je crois que c'est encore l'inverse...
La date de /etc/rc.d/init.d/hotplug est : 2002/12/03
Sûr que Debian doit trainer des problèmes de compatibilité avec Linux 2.4 ou 2.2.

Et non. C'était minable.

[] <==

> si je force pas le chargement de ppp_generic, j'ai pas /dev/ppp (a cause de udev) et donc la connexion ne se lance pas(j'ai rien trouvé d'autre)

Effectivement. En fait ici, c'est pppoatm (via la requête du daemon ppp) qui est chargé et il dépend de ppp_generic. Donc forcément je n'ai pas le "problème" (faux problème pour être honnète). Désolé.

> Starting hotplug subsystem:
> blablabla
> done


Ben on ne parle pas du même hotplug. Tu me parles d'un truc qui est lancé par un script de boot ! Où tu voix du hotplug là dedans (sauf le nom) ?

$ cat /proc/sys/kernel/hotplug
/sbin/hotplug

ça c'est hotplug => http://linux-hotplug.sourceforge.net/(...)

> Euh, dans la sarge a deja ses mises a jour de sécu.

Eh, j'ai lu la mail devel de Debian, et ils ont commencé les backports de sécurité de façon sérieuse (c-à-d suivie) depuis le mois... d'octobre ! (pour Sarge)
Normalement il n'y a pas de mises à jour de sécurité.

> Mais sinon, la détection du matériel dans la sarge: hotplug + udev font du bon boulot.

hotplug et udev qui ne font pas de détection matériel...
Pour les périphériques qui supportent les branchement à chaud, c'est le bus qui reçoit les périphériques qui informent le noyau et le noyau génère un évènement hotplug (qui appelle udev). C'est le driver du bus qui détecte le matos et pas hotplug.
Pour les périphérique qui ne sont pas hotplug (pci) il n'y a pas d'évènement hotplug (je crois qu'il y a une options dans le noyau pour ajouter ça).
Pour les "trucs" exotiques/vieux (genre imprimante sur un port parallèle), il n'y a pas d'évènement hotplug.
Par contre la découverte d'un périphérique (chargement manuel d'un driver) génère un évènement hotplug. J'amais l'inverse.

> cat /etc/modules | tail -2

Chez moi 0 depuis... J'ai oublié.
Pourtant j'ai carte tv, mpeg, 2 cartes sons, imprimante, adsl, etc...
Par contre, ne plus avoir de modules chargés explicitement est beaucoup plus dûr avec udev. Mais il y a d'autres technique pour ça mais qui "casse" le charme de udev. M'enfin, c'est le progrès.

btw, t'es sûre que tu as besoin de ppp_generic ?
Pour nvidia, je peux comprendre.

> Pourtant il est toujours là quand ça parle de Debian pour cracher dessus...

Faut bien tuer le temps parfois.

Certe.

Le "critère" fréquence de sortie, n'est pas le seul à retenir.

Le problème sont les incohérences.
Debian Sarge tourne sur 11 architectures mais n'aura pas AMD64. Il pourrait décider de mettre la priorité sur AMD64 et mettre de côté temporairement arm et m68k. Une fois la distribution sortie, ils finissent le portage vers arm et m68k. Ben non. Debian préfère pénaliser 99 % des utilisateurs. Tant qu'il y aura au moins un utilisateur de arm ou m68k qui traine dans un coin, Debian va tout faire pour préserver cet utilisateur (parabole de la brebis égarée ?) et tant pis si beaucoup se casse de Debian.

Tout le monde parle de sécurité avec Debian mais au moins de 80 % utilise testing/unstable/experimental qui n'ont pas de support de sécurité. C'est "stupide".

C'est l'OS pour tout le monde mais il faut être un expert pour l'utiliser et il faut jongler avec stable, testing, unstable, expérimental, backport pour avoir quelque chose de potable.

Debian se définit par son esprit, pas par sa distribution.
Le seul truc de "positif" sur la distribution c'est apt. Mais presque tout le monde fait la même chose maintenant.

Certains vont dire qu'il y a Sid (ou je ne sais quoi d'autre) qui est super rock and roll. Ben tu prends une Mandrake/SuSE/Fedora/Ubuntu/..., tu l'as mets à jours tous les 6 mois ou 12 mois, ça te prend une journée maxi, t'es heureux.

Maintenant, Debian doit affronter une concurrence nouvelle :
- Ubuntu : On va me dire que ce n'est pas un concurrent, c'est vrai mais Ubuntu peut aussi le devenir. Ubuntu risque de pomper des utilisateurs/développeurs/testeurs. Si Debian n'est plus profitable à Ubuntu, Ubuntu va s'en "débarrasser". Ubuntu ne va pas ralentir sa progression uniquement pour faire plaisir à Debian.
- Gentoo : Communautaire, techinique, à jours, dynamique, sexy pour beaucoup de développeur.

Râtai. Je t'aide, ça commence par min

> Oui, on est bien d'accord

On est bien d'accord. C'était un post "pour rire". Je trouvais ma "formule" marrante.

> mais certains récents évènements

récents ?
Quand devait sortir Sarge ?
Decembre 2003
http://linuxfr.org/2003/08/19/13677.html(...)
La dernière beta est sortie il y a 6 mois ! :
http://linuxfr.org/2004/03/17/15741.html(...)
Après la dernière beta, il y a l'introduction de Gnome 2.6 !
Puis sortie pour le 15 septembre 2004 :
http://www.debianplanet.org/node.php?id=1131(...)
Voilà, on est fin octobre. Si Sarge est passé en freeze, c'est depuis peu alors.

Qui parie sur la sortie de Sarge en 2004 ?

> Il y eut tout d'abord la sortie d'Ubuntu, qui a réussi avec quelques dizaines de développeurs à réussir ce que Debian n'avait pas réussi avec quelques milliers de développeurs...

Non. Ubuntu, ce n'est pas Debian. Debian il y a 50 architectures, 50 branches, 50 exigences et jamais plus de 1 % des développeurs qui travaillent dans la même direction.
Un "ancien" demande, fort logiquement selon moi, de virer testing :
http://lists.debian.org/debian-devel/2004/10/msg01353.html(...)

C'est un flamwar impressionnant qui suit.
Le plus impressionnant, c'est comme Debian s'enfonce.
La situation est intenable mais le groupe dans son ensemble ne veut rien modifier.
Par moment il faut admettre que la situation "sucks grave" et qu'il faut se mettre un coup de pied au cul quitte à faire des dégâts.

Selon moi (c'est évidemment un avis perso), si Debian ne change pas elle va sortir à moyen/long terme des les distributions majeurs.

Râtai, c'était m

> En même temps, les règles ne sont peut-être pas faites pour ceux qui les écrivent...

Les règles sont faites pour refuser des news. Pas les accèpter.

http://www.debian-administration.org/?poll=3(...)

Certe, pas beaucoup de votes mais moins de 20 % utilisent Woody.

http://www.debian.org/News/2004/20041026(...)

Those who frequently update from security.debian.org won't have to update many packages and most updates from security.debian.org are included in this update.

Please note that this update does not produce a new version of Debian GNU/Linux 3.0 but only adds a few updated packages to it.

De "bête" mises à jours que tous les utilisateurs de Woody ont déjà. Ça valait une première page (mais dans la catégorie humour).

> N'est-ce pas une version majeure d'une distribution majeure?

Non, c'est une version mineure d'une distribution m