• # L'annonce sur distrowatch

    Posté par  (site web personnel) . Évalué à 1.

  • # La liste des idées implémentée ou pas

    Posté par  . Évalué à 7.

    La liste des idées pour la 10.1 :
    http://qa.mandrakesoft.com/twiki/bin/view/Main/IdeasForMandrakelinu(...)

    Elle m'a amené à ceci (dans la section RPM) :
    Allow to create patch for updates. Goal is to not to have to download 50 MB when modified files have a size of 5 KB (DavidBaudens) Suse is doing it, and it as discussed on fedora-devel


    Les explications sont là : http://marc.theaimsgroup.com/?l=fedora-devel-list&m=10755040910(...)

    En gros, si j'ai bien compris, au lieu de télécharger des rpms mis à jour, on téléchergera à la place des deltas permettant de recréer le rpm à jour chez soi automatiquement, et donc de limiter la taille des mises à jour à télécharger.

    Ca serait vraiment bien de mettre cela en place. Une des petites caractéristiques qui m'énerve le plus chez Mandrake étant le nombre trop importantes à mon goût de mises à jour après la première installation, à la différence de Slackware par exemple.

    Par contre, je n'avais pas remarqué que SuSE le faisait.
  • # Mandrake 10.1 alpha dispo

    Posté par  (site web personnel) . Évalué à 2.

    Désolé j'avais pas vu le post sur le forum https://linuxfr.org/forums/14/2513.html(...)
  • # udev

    Posté par  . Évalué à 2.

    > udev ou pas udev ? that is the question.

    Il y a eu un long thread sur Fedora relatif à l'utilisation de udev ou non.
    udev semble l'"emporter". Mais c'est de peu (la décision finale n'est toujours pas prise il me semble).
    Donc "udev ou pas udev ?", là n'est pas vraiment la question quand certains hésitent autant et ont des difficultés pour avoir des arguments "massu" en faveur de udev (il reste l'"éternel" problème de chargement de module à la demande que ne peut pas résoudre udev).
    • [^] # Re: udev

      Posté par  (site web personnel) . Évalué à 4.

      Effectivement, le problème est surtout comment faire une distro qui puisse gérer correctement le branchement à chaud (et le débranchement tant qu'à faire) des périphériques usb ou autres.

      On vois dans beaucoup de posts que ça marche, certes mais souvent à peu près (un peu comme supermount)

      Personnellement, je trouve qu'a ce niveau là (ce n'est pas un troll mais une constatation issue de ma seule expérience personnelle et qui n'as donc pas plus de valeur que ça), le seul système qui marche vraiment très bien est mac OS X.

      La question serait donc plutôt est-ce que udev améliore les choses en ce domaine qui deviens de plus en plus crucial puisque je rappelle qu'il se vend de plus en plus d'ordinateurs ou ports autres que usb et firewire ne sont plus qu'un lointain souvenir.
      • [^] # Re: udev

        Posté par  (site web personnel) . Évalué à 2.

        udev n'est pas encore utilisable pour la simple et bonne raison que le noyau lui-même n'est pas encore passé complétement sur sysfs et que les pilotes ayant migré sur sysfs ne fournisse pas encore suffisemment d'informations pour être convenablement exploité par des scripts.

        Exemple : ce n'est que il y a seulement quelque jours que l'état "amovible" d'un périphérique est rapporté par sysfs. C'est le type d'informations indispensable à connaitre pour savoir s'il faut scruter pour la présente de cartes dans un lecteur de carte flash usb... et donc monter les partitions automatiquement lorsque l'on insére une carte dans le lecteur et non lorsque l'on branche _le lecteur_ sur le bus usb !

        Ce n'est qu'un exemple parmi d'autres, il y a encore énormement de sous-systèmes qui ne sont pas exploitable de manière transparente pour udev et hotplug et donc pour l'utilisateur final...

        Je pense qu'il va falloir attendre jusqu'au noyau 2.6.15 pour avoir une chaîne complète hotplug / udev / hal / dbus réelement exploitable au quotidien et pas des hacks à 2 francs 6 sous qui ne marche que trés moyennement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.