blino a écrit 153 commentaires

  • [^] # Re: Superbe distrib

    Posté par . En réponse au journal Sortie de la Release Candidate de Mageia. Évalué à 2.

    Le kernel 3.3.5, qui contient ce fix, vient d'arriver sur les miroirs Mageia Cauldron, ce sera donc la version finale Mageia 2.

  • [^] # Re: Superbe distrib

    Posté par . En réponse au journal Sortie de la Release Candidate de Mageia. Évalué à 4.

    Ce oops a l'air spécifique aux machines Dell.
    Le patch suivant devrait corriger le problème, et nous allons l'intégrer dans la version finale si possible (sinon, ce sera en update)
    https://lkml.org/lkml/2012/4/24/403

  • [^] # Re: compléments

    Posté par . En réponse au journal Sortie de la Release Candidate de Mageia. Évalué à 6.

    Xfce (4.9 apparemment, donc la pre-4.10) est disponible dans les dépôts, il suffit d'installer le paquet task-xfce (ou task-xfce-minimal).
    LXDE est également disponible.

  • [^] # Re: mini-forks

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

    > C'est ConsoleKit qui le fait (via hal/dbus ?).
    > Donc l'utilisateur test peut utiliser la carte son. Il n'a pas besoin d'appartenir à un groupe. Les acl sont utilisés aussi pour fast-user-switch.

    ConsoleKit maintient une liste d'utlisateurs "console", et lors d'une modification de cette liste, hal réapplique les ACLs sur les devices, cf /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi

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

    Cf http://fedoraproject.org/wiki/Releases/FeatureRemovePAMConso(...)

    >> Et il n'y a pas vraiment d'équivalent qui permet de détecter le module à utiliser pour chaque périphérique.
    > Tu parles de problèmes qui devrait être réglé en upstream. Fedora n'utilise pas ldetect ou autre. S'il y a un problème, il est corrigé en upstream (comme ça tout le monde en profite :-)).

    C'est un peu comme mkinitrd, il n'y a pas vraiment d'"upstream".
    Rien n'empêche les autres distributions de reprendre nos outils.

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

    > Fedora utilise kudzu, mais pour des raisons historiques. kudzu va être viré.
    > A vrai dire, je ne sais même plus exactement ce que fait kudzu :-)
    > Kudzu ne fait pas de détection de matériel, il permet principalement de détecter un changement de matériel. Si par exemple un carte réseau a été ajoutée entre deux boots, il propose de la configurer (ce qu'on peut faire sans kudzu).

    Il a quand même besoin de détecter du matériel pour proposer de le configurer, et c'est ce qu'il fait avec pas mal de workarounds :-) (cf le code de Kudzu dans le CVS de RedHat).

    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 ...
    Et chaque distribution a ses besoins particuliers, et surtout une vision différente de la manière dont il faut détecter et configurer le matériel.
  • [^] # Re: mini-forks

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

    >> Il n'y a jamais eu de mini-fork d'udev dans Mandriva.

    > Mouaiff.
    > Un première version était une repompe de FC3 (et c'est normal). Puis ça a dérivé et pour la 2008 (si j'ai bonne mémoire), c'est revenu sur ce que fait Fedora.

    Chaque distro a adapté ses règles en fonction des noms de groupes, de la version du kernel, du chemin des binaires, ...
    Nos règles ont été simplifiées récemment, puisqu'un ensemble de règles par défaut en maintenant distribué upstream.

    > Que pouvez vous avoir pour udev qui est vous est utile et ne l'est pas aux autres ?

    Très bien, regardons un peu nos modifications dans udev ...
    http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/u(...)

    Les sources upstream udev + Fedora :
    udev-118.tar.bz2
    start_udev

    Nos adaptations de packaging :
    udev-109-MAKEDEV.patch
    udev-114-libudevdir.patch

    Nos adaptations pour la création de devices statiques (puisqu'on n'utilise pas le même makedev) :
    create_static_dev_nodes
    default.nodes
    udev-114-devices_d.patch

    Nos règles spécifiques de groupes :
    50-udev-mandriva.rules

    Nos adaptations aux règles de colplug pour éviter de charger des modules non-désirables :
    udev-117-coldplug.patch

    Des helpers d'import d'anciennes règles hotplug :
    udev_import_usermap
    hotplug-usb.distmap
    hotplug-usb.handmap

    Nos helpers et règles de nommage persistant réseau + cdrom :
    62-create_persistent.rules
    62-net.rules
    udev_cdrom_helper
    udev_copy_temp_rules
    udev_net.sysconfig
    udev_net_action
    udev_net_create_ifcfg
    udev_net_name_helper
    udev_persistent_lib.sh

    Ces derniers outils devraient être rapidement remplacés par les helpers + règles upstream, qui ont été introduites légèrement après les nôtres.

    > Et sans froisser Mandriva, la détection du matériel n'a pas été développé par Mandriva. C'est le noyau, c'est udev, etc, mais ce n'est pas Mandriva (ni Fedora).

    Ça fait plus de 5 ans que nous avons une librairie (ldetect) de détection de devices, qui indique le meilleur module à utiliser pour chaque périphérique (en fonction de listes dans ldetect-lst).
    Ça s'est grandement amélioré très récemment, avec l'apparition généralisée des modalias dans les modules, mais ce n'est pas encore parfait. Par exemple, plusieurs modules peuvent fournir le même modalias, il faut des règles pour choisir celui qui sera utilisé.

    Et il n'y a pas vraiment d'équivalent qui permet de détecter le module à utiliser pour chaque périphérique.
  • [^] # Re: mini-forks

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

    >> Au hasard, des noms de groupe auxquels donner certains devices qui ne sont pas les mêmes que chez d'autres ?

    > Ce n'est pas udev, ça doit être MAKEDEV ou pam_console (qui va être remplacé par ConsoleKit). C'est seulement un fichier de configuration.

    Eh non, dommage, les noms de groupes sont toujours assignés par udev.
    ConsoleKit/PolicyKit ne permettent que d'appliquer des ACLs aux devices, ils ne changent pas le groupe (au contraire de pam_console).
  • [^] # Re: mini-forks

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

    Il n'y a jamais eu de mini-fork d'udev dans Mandriva.
    Il y a des règles additionnelles, mais on ne peut appeler ça un fork ...
    Nos patchs qui sont utiles à toutes les distributions sont remontés upstream, mais nous sommes obligés d'en conserver quelques-uns liés aux spécificités de la distribution (packaging, système de détection de matériel).

    Quant à mkinitrd, la plupart des distributions ont leur propre implémentation, et c'est difficile d'isoler un projet "upstream" (initramfs-tools, yaird, mkinitrd Fedora, mkinitrd OpenSuse, mkinitrd Mandriva ...).

    Nous allons nous rapprocher du mkinitrd Fedora, mais là encore, nous avons besoin d'adaptations à notre packaging, ou à la façon dont sont configurés les disques. Ce ne sera pas exactement un fork, puisqu'il sera régulièrement fusionné avec la version RedHat, tout comme nous le faisons pour initscripts.

    Ce n'est pas juste pour le plaisir que nous écrivons des patchs supplémentaires par rapport aux packages de Fedora (par exemple), mais parce que notre politique de packaging est différente, et que nos méthodes de configuration sont différentes.
  • [^] # Re: Restauration de la Mandriva Flash

    Posté par . En réponse à la dépêche Monkey Studio, Gogh Project et 2008 Mandriva Flash 4GB. Évalué à 8.

    Un CD de restauration est disponible sur notre site :
    http://mandriva.com/fr/produit/mandriva-flash-2008
    Il permet de réinitialiser certaines parties de la clé, ce qui devrait résoudre le problème d'espace saturé.
  • [^] # Re: Sans oublier quelques jeux de voiture...

    Posté par . En réponse à la dépêche Des jeux pour GNU/Linux. Évalué à 3.

    Et également VDrift (GPL, http://vdrift.net/ ), qui est plus axé simulation, et a des graphismes assez réussis.
  • [^] # Re: Du côté de Mandriva :

    Posté par . En réponse à la dépêche Des jeux pour GNU/Linux. Évalué à 3.

    Et Those Funny Funguloids est disponible pour Mandriva Cooker (en contrib) \o/
  • [^] # Re: Tempérer la nouvelle

    Posté par . En réponse à la dépêche Dell choisit Ubuntu pour ses PC. Évalué à 5.

    Personnellement j'utilise Mandriva avec KDE depuis la 7.02 avec quelques infidélités passagères (Suse, Ubuntu) périodiques par curiosité et trouve la 2007.1 très bonne, mais sincèrement une fois installé ce qui compte c'est la communauté:
    les forums

    Mandriva héberge des forums gratuits sur le Club : http://forum.club.mandriva.com/

    l'accès à la doc

    La doc est disponible sous forme de paquetages dans la distribution, ainsi que sur le site web de Mandriva.

    les maj

    Les mises à jour sont publiques, et disponibles facilement depuis l'applet de notification de mise à jour (désormais gratuite elle aussi)

    les sources de logiciels

    Justement, il n'y a pas besoin d'une dizaine de sources supplémentaires, beaucoup de paquetages sont disponibles dans le media Mandriva Contrib, et dans les media du groupe PLF.
  • [^] # Re: Une bonne nouvelle pour Linux...

    Posté par . En réponse à la dépêche Dell choisit Ubuntu pour ses PC. Évalué à 10.

    On pourra pas dire que ex-mandrake ai fait quelque chose pour diffuser sa distrib : ils auraient pu offrir des CD ou des produits dérivés (poster, ...) aux clubs faisant la promo dans les ecoles d'inge. Non, ils le faisaient pas

    Pourtant, Mandriva diffuse des versions CD de Mandriva One, des posters et des goodies dans les LUGs, les écoles d'ingés et toutes les associations qui organisent des install-parties.

    Il suffit de contacter le responsable LUGs de Mandriva :
    http://www.mandriva.com/en/company/contact/community
  • [^] # Re: Zont fait exprès ?

    Posté par . En réponse à la dépêche Ubuntu 7.04 : le faon est sur ses pattes. Évalué à -2.

    Je me suis renseigné sur le site officiel. C'est une petite distribution forké de Redhat, sans grande prétention

    On se croirait en 1998 /o\
    Ça fait bien longtemps que Mandriva Linux s'est détachée de Redhat et maintient ses propres packages.

    qui cherche surtout a intégrer la langue française dans le gestionnaire RPM.

    Mandirva Linux est une des distribution les mieux traduites (si ce n'est celle qui est localisée dans le plus grand nombre de langues), les outils Mandriva sont par exemple traduits dans 70 langues, c'est bien loin d'être une distro seulement "frenchy".

    Pas vraiment novatrice, mais intéressante quand même.

    Mandriva Linux intègre, en plus de compiz et beryl, le bureau Metisse, qui est un projet de recherche français autrement plus innovant que les autres "bureaux 3D".
    Sans compter tous les outils de configuration Mandriva qui différencient la distribution des autres.
  • [^] # Re: C'est nil !

    Posté par . En réponse au journal Sortie de la Mandriva Spring 2007.1. Évalué à 3.

    Nul doute qu'en ce cas, cette Mandriva plaira au troisième age !

    Ça plaira surtout au troisième étage de la rue d'Aboukir !
  • [^] # Re: CINES

    Posté par . En réponse au journal Lettre ouverte de Bancilhon. Évalué à 4.

    Le noyau n'est pas mis à jour automatiquement, mais il est disponible dans l'interface de sélection des mises à jours (il est simplement non sélectionné par défaut).
    Pour le mettre à jour automatiquement, il suffit d'enlever les restrictions sur kernel-latest dans le fichier de configuration /etc/urpmi/skip.list
  • [^] # Re: Mouais...

    Posté par . En réponse au journal Lettre ouverte de Bancilhon. Évalué à 4.

    Hé non, les résumés et descriptions de packages sont désormais traduits dans Mandriva 2007.1
  • [^] # Re: Re:

    Posté par . En réponse au journal A propos des draketools. Évalué à 4.

    Et pour drake :

    (ce serait plutôt "drakx")

    Il y a quoi pour configurer un DNS chez Mandriva ?

    drakwizard ?
  • [^] # Re: Qu'est-ce que tu veux

    Posté par . En réponse au journal A propos des draketools. Évalué à 5.

    Fedora a développé NetworkManager qui est aussi repris par Ubuntu et Novell. La seulement question que je me pose, c'est quand Mandriva va reprendre NetworkManager...

    Nous avons packagé NetworkManager dans Mandriva, donc il est tout à fait possible de l'utiliser.
    Par contre, il est difficile de l'utiliser par défaut dans l'état actuel des choses, il est difficilement administrable, ne fonctionne (pour l'instant) qu'une fois un utilisateur loggué, et duplique les scripts réseaux système.
    Cf http://wiki.mandriva.com/en/Projects/EasyWifi/Development/Ne(...) (ça date un peu)
  • [^] # compilation sur x86_64

    Posté par . En réponse au journal Metisse dans mandriva!. Évalué à 4.

    Les développeurs de Mandriva ont envoyé des patchs aux auteurs de Metisse pour corriger les problèmes de compilation sur x86_64 (en gros pour glSelectBuffer) :
    http://lists.lri.fr/pipermail/metisse/2007-January/000133.ht(...)
  • [^] # Re: excellent !

    Posté par . En réponse au journal Metisse dans mandriva!. Évalué à 3.

    La commande est draklive-install, et devrait être disponible dans ce live Metisse
  • [^] # Re: et bientot dans votre Cooker prés de chez vous

    Posté par . En réponse au journal Le client second life passe en gpl. Évalué à 5.

    Et comme à Mandriva on n'est pas sectaire, voilà le fichier spec et quelques patches permettant à Second Life de compiler avec gcc 4 :
    http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/s(...)

    Pour plus d'infos sur les sources: http://wiki.secondlife.com/wiki/Get_source_and_compile

    Et pour participer au développement ou se renseigner sur la compilation plus en détails, il y a également une mailing list, un forum, ainsi qu'un canal IRC :
    http://wiki.secondlife.com/wiki/Developer_communication_tool(...)
  • [^] # Re: bonne phrase !

    Posté par . En réponse à la dépêche Un bureau 3D dans la poche !. Évalué à 2.

    Il est où le site de développement ? Les listes de diffusion ? Le dépôt CVS/SVN/etc ?

    Toutes les infos sont centralisées ici :
    http://mdv.vmlinuz.ca/Development/Packaging/Tools/DrakLive
    (il se peut que cette adresse ne soit plus valable dans quelques jours, le wiki est en cours de migration)
  • [^] # Re: bonne phrase !

    Posté par . En réponse à la dépêche Un bureau 3D dans la poche !. Évalué à 4.

    Pour initrd, tu devrais regardé du côté de Red Hat (c'est eux qui le développe quasi exclusivement). Dans FC6, en standard, tu peux bouter sur une clée USB.

    Je suis au courant de ce que fait RedHat, Mandriva utilise également mkinitrd (assez lourdement patché).
    Mais les distributions live ont des besoins plus spécifiques, comme pouvoir monter une image squashfs en union avec une image ext2 pour créer le root du système. Et ce petit script initrd a été refait "from scratch" par Mandriva, pour coller à ces besoins.
    Et regarde les contributions de Mandriva à initrd, ben il n'y a presque rien pour ne pas dire rien.

    Elles ne sont pas forcément remontées "upstream", puisque chaque distro a souvent son implémentation propre de la détection de matérial, de la configuration du RAID, de LVM, ...
    Autre point pour le configuration (l'auto-configuration). Fedora a lancé un projet depuis plus de 2 ans qui est linux stateless.

    Et le service harddrake est dans Mandriva depuis plus de 4 ans.

    M'enfin, libre à toi de croire que Mandriva a tout fait.

    Merci, mais je sais très bien ce que j'ai développé pour Mandriva One et Mandriva Flash ...
  • [^] # Re: bonne phrase !

    Posté par . En réponse à la dépêche Un bureau 3D dans la poche !. Évalué à 2.

    ça tombe bien, ce n'est pas une contribution au libre

    L'outil de création de ces systèmes live est libre, les outils de configuration de matériel de Mandriva sont libres. Ce n'est pas encore assez libre ?
  • [^] # Re: bonne phrase !

    Posté par . En réponse à la dépêche Un bureau 3D dans la poche !. Évalué à 7.

    Il ne s'agit certainement pas de deux ou trois bricoles d'amateur, le travail d'intégration de ces technologies n'est pas négligeable.

    Les technologies comme squashfs et unionfs sont certes nécessaires mais pas suffisantes pour créer un système live USB de bonne finition. Pour arriver à ce niveau, il ne suffit pas d'installer "à la main" un système dans un chroot, de le compresser, et de le déposer sur une clé USB. L'automatisationr de la procédure aide énormément à avoir des résultats reproductibles et propres. C'est dans ce but que l'outil draklive de génération de systèmes "live" a été développé.

    Il se charge également de la création d'un initrd permettant de monter les systèmes de fichiers et de les vérifier avant de démarrer le système, ce qui n'est pas forcément une tâche triviale.

    Il ne faut pas non plus oublier tout le travail fait pour la détection et l'auto-configuration de matériel, même s'il est plus ou moins intégré au développement de la distribution "classique".

    De plus, un produit de ce type n'est pas lancé sans des contrôles d'assurance-qualité, qui ne peut pas être fait à une si grande échelle par n'importe qui.

    Donc non, il ne s'agit pas de deux ou trois bricoles, et certainement pas seulement de marketing. Même s'il s'agit principalement d'intégration, ce n'est pas une contribution anodine au libre.