• [^] # Re: mini-forks

    Posté par . En réponse au journal Manbo-Labs. Évalué à 0.

    > Tous les utilisateurs loggués physiquement sur la machine ont le droit d'accès aux devices spécifiés dans ce fichier.

    Non. Du moins pas en même temps.

    > C'est un peu comme mkinitrd, il n'y a pas vraiment d'"upstream".

    Désolé, mais quand on regarde l'historique de "votre" mkinitrd, l'upstream est le mkinitrd de Fedora.

    > Rien n'empêche les autres distributions de reprendre nos outils.

    Très juste. C'est par exemple ce qui a été fait avec rpmlint. Pas sous la forme d'un "mini-fork", mais participation upstream.

    > Apparement, les 2 implémentations qui ressortent dans ce domaine sont ldetect et kudzu.

    Comme je l'ai dit, je ne suis pas un spécialiste kudzu. Mais kudzu ne fait plus grand chose.

    http://fedoraproject.org/wiki/Anaconda/Features/NoMoreKudzu
    anaconda is the only thing keeping kudzu around, for the most part. Everything that it uses it for can be handled by the 'normal' mechanisms that the OS uses for probing, module loading, and device discovery these days.

    Bref, pour Fedora il n'y a plus à avoir de kudzu ou autre.
    La présence de kudzu est aujourd'hui un bug (qui doit être corrigé).

    > Il a quand même besoin de détecter du matériel pour proposer de le configurer

    Faudrait s'entendre sur le vocabulaire.
    Kudzu ne détecte pas le matériel, il le liste. Le matériel a déjà été détecté via les mécanisme classique (et upstream) de Linux.
    Si je fais "ls /tmp", je ne détecte pas le contenu de "/tmp", je le liste.

    > Il a quand même besoin de détecter du matériel pour proposer de le configurer

    Configurer comme on configure X11, comme on configure la fréquence d'un carte tv ou radio, etc.... On n'est plus dans la configuration bas niveau, mais dans l'utilisation du hardware déjà détecté et configuré (pour le bas niveau (irq, ioport, paramètre des modules (puisqu'ils sont déjà chargé), etc)).

    > et c'est ce qu'il fait avec pas mal de workarounds :-)

    D'accord, mais c'est erreur. Le matériel (et pas le logiciel type X11, etc) doit être configuré sans kudzu. Je te paris qu'il le sera à moyen terme (F9 voire F10).

    > Dans Mandriva, la reconfiguration de matériel est faite avec le service harddrake, écrit en Perl et se basant sur ldetect, c'est difficile d'envisager une fusion des 2 deux outils ...

    Si Fedora peut virer kudzu, vous pouvez virer ldetect. Peut-être que ldetect ou kudzu resteront mais sous une autre forme. Par exemple uniquement pour voir s'il y a un ajout de matériel entre deux boot (typiquement l'ajout d'une carte PCI) et prendre les actions nécessaires. Si la carte graphique a été changée, il est clair qu'il ne faut pas lancer X11 sans le reconfigurer. Quoique Fedora utilise massivement l'autoconfiguration de X11 et peut-être qu'un jour par défaut il n'y aura plus de /etc/X11/xorg.conf. Et en réalité, c'est déjà fait pour linuxstateless.

    > Et chaque distribution a ses besoins particuliers

    Besoins ou caractéristiques ou exigences ou cibles ?
    Les exigences et la cible de Fedora et RHEL ne sont pas les mêmes. Mais pour les besoins au niveau de l'OS c'est la même chose.
    Pour la détection/configuration, c'est le même besoin pour tout le monde. Une même solution peut marcher pour tout le monde.

    En partant avec ton raison, il faut des noyaux linux différent, des X11 différents, etc. Ça sucks.
    Autre aspect, comme tu fais pour concilier ton avis avec l'annonce de ce journal ?
    L'annonce dit que TurboLinux et Mandriva vont utiliser le même mkinitrd par exemple...
    Tu es contre ?

    > , et surtout une vision différente de la manière dont il faut détecter et configurer le matériel.

    Plus le temps passe, et plus c'est faux.
    Je suis sûr qu'à moyen terme tout le monde va faire comme Fedora (c-à-d ne pas avoir de truc spécifique).