> le design de gnome 2.8 dépend du kernel 2.6, de dbus et de hal
Hummm...
Je n'ai pas essayé mais gnome 2.8 doit surement être compilable sans Hal. Le nombre de paquet qui utilise Hal est assez limité.
Hal a besoin d'udev. En fait Hal a "seulement" besoin de hotplug mais sans udev il y a des problèmes de permission d'accès aux périphériques et Gnome-volume-manager devient moins intéressant. Un périphérique est ajouté mais tu ne peux pas l'utiliser... Il a fallut ajouter, "sur le tard", dans udev un moyen pour changer les permissions des fichiers dans /dev. Avant c'était uniquement fait au login.
Donc pour Hal, il faut Linux 2.6.
> il traiterait tout ça de "bloat insecure".
Pour bloat, je ne suis pas d'accord. La mécanique udev est certe subtile mais pas "bloat". C'est un /dev dynamique mais côté userland avec des hooks sur le noyau donc forcément ce n'est pas aussi "pure" qu'un /dev static ou uniquement géré par le noyau (devfs). Mais ça permet des choses indispensables pour un Desktop moderne.
Pour "insecure", il n'a pas totalement tord. Il y avait des problèmes et il reste un problème. Hal a la "facheuse" habitude de rendre montable par l'utilisateur (pas root) tout ce qu'il trouve. Avant pour monter un périphérique il fallait l'expliciter (via fstab). Ça va être corrigé dans peu de temps (Hal sera configurable pour indiquer ce qu'il gérer dans fstab).
> Donc tout ça me parait bizarre, gnome 2.8 serait un bloat insecure et personne ne le saurait et pour remédier à ça il préférerait ne pas fournir sa version de gnome et laisser ses utilisateurs utiliser quelque chose au design moisi?
J'ai suivit FC3 de loin, ajouter udev et hal est assez "douloureux".
A ça, il y a deux raisons :
* udev :
- udev doit être embarqué dans initrd ou il faut aussi un /dev statiques temporaire
- rc.sysinit doit être adapté pour udev
- Il n'y a plus de chargement à la demande des drivers lorsque ça passe par un fichier spécial. Il faut donc détecter au boot les drivers necessaires et les charger.
- "install" de modprobe.conf ne marche pas s'il faut les fichiers spéciaux du périphérique.
* C'est tout nouveau comme concept dans Unix : L'argument parait "bête" mais ça soulève plein de problèmes qu'il faut résoudre en pensant différament.
Par exemple, pour restaurer la configuration de la carte son, avant on utilisait modprobe.conf. Ça ne marche plus car avec udev les fichiers spéciaux sont créés _après_ insmod. Donc "alsactl restore" par modprobe ne marche pas car alsa ne trouve pas les fichiers spéciaux. De plus, udev (via hotplug) sépare les services et les modules. Par exemple, à une carte son, il peut y avoir plusieurs services (pcm, mixer, etc). Pour modprobe, c'est un évènement (chargement d'un module). Pour udev, c'est autant d'évènements qu'il y a de services. Dans ce contexte, il n'est pas facile de savoir si le driver de la carte son est disponible ou en cours de chargement (ça a aussi montré quelques bugs dans les drivers :-)).
Corriger tous ces nouveaux problèmes a demandé un effort considérable. Il serait instructif de faire une comparaison entre FC3T1 et FC3T3 (qui sort aujourd'hui) pour voir la quatité de travail réalisé autour d'udev/hal les fichiers d'init etc. C'est énorme compte tenu du délai et que ces projets sont bas niveau. Quand udev ne marche pas, plus rien ne marche :-)
Peut-être que le mainteneur de Slack a été "dégouté" par ça. Surtout s'il veut conserver la compatibilité avec Linux 2.4. C'est faisable mais si j'étais mauvaise langue je dirais "qu'il faut vraiment l'avoir que ça à foutre" pour s'attarder sur la compatilité avec Linux 2.4.
Ça soulève un problème intéressant et nouveau. Les distributeurs qui ont une grosse "force de frappe" mènent Linux à un rythme que les "faibles" ne peuvent pas toujours suivre.
Ajoutons que le mainteneur de Slack est tout seul et qu'il utilise KDE. Dans ce cas, je comprend qu'il n'ait plus la motivation de s'arracher les cheveux sur Gnome.
[^] # Re: 2 notes:
Posté par Ayrton . En réponse à la dépêche Dropline Gnome 2.8 disponible (depuis le 07/10/2004). Évalué à 7.
Hummm...
Je n'ai pas essayé mais gnome 2.8 doit surement être compilable sans Hal. Le nombre de paquet qui utilise Hal est assez limité.
Hal a besoin d'udev. En fait Hal a "seulement" besoin de hotplug mais sans udev il y a des problèmes de permission d'accès aux périphériques et Gnome-volume-manager devient moins intéressant. Un périphérique est ajouté mais tu ne peux pas l'utiliser... Il a fallut ajouter, "sur le tard", dans udev un moyen pour changer les permissions des fichiers dans /dev. Avant c'était uniquement fait au login.
Donc pour Hal, il faut Linux 2.6.
> il traiterait tout ça de "bloat insecure".
Pour bloat, je ne suis pas d'accord. La mécanique udev est certe subtile mais pas "bloat". C'est un /dev dynamique mais côté userland avec des hooks sur le noyau donc forcément ce n'est pas aussi "pure" qu'un /dev static ou uniquement géré par le noyau (devfs). Mais ça permet des choses indispensables pour un Desktop moderne.
Pour "insecure", il n'a pas totalement tord. Il y avait des problèmes et il reste un problème. Hal a la "facheuse" habitude de rendre montable par l'utilisateur (pas root) tout ce qu'il trouve. Avant pour monter un périphérique il fallait l'expliciter (via fstab). Ça va être corrigé dans peu de temps (Hal sera configurable pour indiquer ce qu'il gérer dans fstab).
> Donc tout ça me parait bizarre, gnome 2.8 serait un bloat insecure et personne ne le saurait et pour remédier à ça il préférerait ne pas fournir sa version de gnome et laisser ses utilisateurs utiliser quelque chose au design moisi?
J'ai suivit FC3 de loin, ajouter udev et hal est assez "douloureux".
A ça, il y a deux raisons :
* udev :
- udev doit être embarqué dans initrd ou il faut aussi un /dev statiques temporaire
- rc.sysinit doit être adapté pour udev
- Il n'y a plus de chargement à la demande des drivers lorsque ça passe par un fichier spécial. Il faut donc détecter au boot les drivers necessaires et les charger.
- "install" de modprobe.conf ne marche pas s'il faut les fichiers spéciaux du périphérique.
Harald Hoyer a fait une bonne présentation de l'utilisation d'udev dans FC3 :
http://people.redhat.com/~harald/udev.html(...)
* C'est tout nouveau comme concept dans Unix : L'argument parait "bête" mais ça soulève plein de problèmes qu'il faut résoudre en pensant différament.
Par exemple, pour restaurer la configuration de la carte son, avant on utilisait modprobe.conf. Ça ne marche plus car avec udev les fichiers spéciaux sont créés _après_ insmod. Donc "alsactl restore" par modprobe ne marche pas car alsa ne trouve pas les fichiers spéciaux. De plus, udev (via hotplug) sépare les services et les modules. Par exemple, à une carte son, il peut y avoir plusieurs services (pcm, mixer, etc). Pour modprobe, c'est un évènement (chargement d'un module). Pour udev, c'est autant d'évènements qu'il y a de services. Dans ce contexte, il n'est pas facile de savoir si le driver de la carte son est disponible ou en cours de chargement (ça a aussi montré quelques bugs dans les drivers :-)).
Corriger tous ces nouveaux problèmes a demandé un effort considérable. Il serait instructif de faire une comparaison entre FC3T1 et FC3T3 (qui sort aujourd'hui) pour voir la quatité de travail réalisé autour d'udev/hal les fichiers d'init etc. C'est énorme compte tenu du délai et que ces projets sont bas niveau. Quand udev ne marche pas, plus rien ne marche :-)
Peut-être que le mainteneur de Slack a été "dégouté" par ça. Surtout s'il veut conserver la compatibilité avec Linux 2.4. C'est faisable mais si j'étais mauvaise langue je dirais "qu'il faut vraiment l'avoir que ça à foutre" pour s'attarder sur la compatilité avec Linux 2.4.
Ça soulève un problème intéressant et nouveau. Les distributeurs qui ont une grosse "force de frappe" mènent Linux à un rythme que les "faibles" ne peuvent pas toujours suivre.
Ajoutons que le mainteneur de Slack est tout seul et qu'il utilise KDE. Dans ce cas, je comprend qu'il n'ait plus la motivation de s'arracher les cheveux sur Gnome.