Mandriva et les japonais de Turbolinux viennent de créer un groupe de travail qui porte le nom de "Manbo-Labs", l'idée est de s'associer pour travailler sur les briques de base communes aux deux distribs : gcc, glibc, rpm, le kernel, bin-utils, mkinitrd, udev.
Bon une fois passé l'annonce et ses détails, on peut se rappeller pour la petite histoire que l'idée n'est pas nouvelle (LSB, DCC, Linux Core Consortium, UnitedLinux,...) et que dans cette liste mandriva et turbolinux font figure d'usual suspects dans ce genre d'initiative (Mandriva ayant racheté le troisième larron, Connectiva).
l'annonce presse -> http://www.mandriva.com/enterprise/en/company/press/mandriva(...)
l'annonce sur la ML -> http://archives.mandrivalinux.com/cooker/2008-01/msg00672.ph(...)
Journal Manbo-Labs
16
jan.
2008
# Re:
Posté par IsNotGood . Évalué à -1.
Mandriva a "participé" à LCC. Bilan : fiasco.
Je vais me mouiller, je pense que ça va encore être un fiasco.
> gcc, glibc, rpm, le kernel, bin-utils, mkinitrd, udev.
Ils feraient mieux de bosser en upstream et plus particulièrement pour les deux derniers.
Ça fait depuis des années que Red Hat/Fedora maintient mkinitrd et udev (packaging/exploitation sous Linux pour ce dernier). SuSE fait de même de son côté.
À chaque fois Mandriva fait des "mini-fork" et se synchronise avec Fedora. La dernière Mandriva a foutu son "mini-fork" d'udev pour revenir à Fedora.
Es-ce la faute à Mandriva ou Fedora ?
Qu'importe. On voit seulement que c'est un problème culturel, ou d'objectif, ou de calendrier, etc et non de partenariat.
[^] # Re: mini-forks
Posté par blino . Évalué à 10.
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: mini-forks
Posté par IsNotGood . Évalué à 1.
C'est pourquoi les autres distributions bossent si peu avec Red Hat ?
Certes, on va dire que Red Hat ne le fait pas non plus (sauf un peu avec Debian), mais Red Hat est très "tendance upstream". C'est probablement le distributeur (via Fedora notamment) qui bosse le plus upstream, qui s'implique le plus dans l'upstream. D'ailleurs Fedora est relativement peu patcher contrairement à ce que laisser croire son nombre d'innovation (les développements sont faits dans la mesure du possible directement en upstream, évidemment avec l'accord du mainteneur upstream). La majorité des projets Red Hat a leur propre site web et il faut gratter pour savoir que c'est un projet Red Hat.
Il y a des développeurs Red Hat qui bossent principalement sous .... Debian. Et ça ne dérange personne. Par exemple le mainteneur de pulseaudio est un employé Red Hat et il bosse sur Debian.
Red Hat a aussi une "force de développement" qui lui autorise une certain (mais pas totale, loins de la) autonomie.
Alors, pourquoi ne pas bosser plus avec Red Hat ? Je veux dire plus spécifiquement avec Fedora ?
> 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.
> Nos patchs qui sont utiles à toutes les distributions sont remontés upstream
Que pouvez vous avoir pour udev qui est vous est utile et ne l'est pas aux autres ?
> 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).
Packaging : oui.
système de détection de matériel : non.
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).
> Quant à mkinitrd, la plupart des distributions ont leur propre implémentation, et c'est difficile d'isoler un projet "upstream"
Très bonne remarque.
> Nous allons nous rapprocher du mkinitrd Fedora, mais là encore, nous avons besoin d'adaptations à notre packaging,
Très bien.
Avez vous envisagé de passer directement au mkinitrd de Fedora ?
De remonter les problèmes ou limitations que vous rencontrez ?
Avez vous lancé une discussion avec Fedora pour voir si Mandriva pouvait fusionné ses spécificités en upstream ?
> Ce ne sera pas exactement un fork, puisqu'il sera régulièrement fusionné avec la version RedHat
C'est un fork. Désolé.
Vous les remontés quand vos modifs ?
Quasiment jamais.
Lorsque vous faites des modifs, en discutez vous avec l'upstream (qui ici est manifestement le mkinitrd de Fedora) ?
Ben non.
Peut-être, et très probablement, vous avez des idées qui vont plaire à Fedora. Au-lieu de bosser dans votre coin et seulement repomper le boulot de Fedora, bossez avec Fedora.
> 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.
OK, OK, OK, le packaging est différent. M'enfin, ce n'est pas le bout du monde. J'ai vu des .spec qui marchent pour Fedora, Mandriva et OpenSuse avec seulement une poignée de "if ....".
M'enfin, ton message est "incongru".
D'un côté il y a une annonce pour dire que deux distributions vont faire des choses en commun, et de l'autre tu dis que ce n'est pas possible avec Fedora. Chercher l'erreur...
Tout ça c'est culturel et c'est presque tout.
Si on va sur les mailing Fedora ou projets Red Hat, on ne voit jamais Mandriva (ou hypra rarement). On voit, certe très ponctuellement, du Ubuntu, du Debian et du SuSE.
Si on va sur cooker de Mandriva (je n'y suis plus allez depuis longtemps), on voit beaucoup de référence à Fedora (mais très rarement des développeurs Fedora) avec "synchronisation avec la dernière version Fedora", "patch Fedora", etc.
On voit aussi beaucoup de "Fedora ça pue, on va faire à notre propre sauce".
Le tableau c'est "on ne peut pas se passer du boulot de Fedora ou il nous est très profitable ET on ne veut pas montrer qu'on est lié à Fedora". Je trouve ça ridicule.
Un exemple de ce que j'aimerais voir. Imaginons que Mandriva veut utiliser libvirt/virt-manager. Mandriva évalue et pose des questions en upstream. Mandriva veut faire des modifications. Mandriva pourrait en discuter upstream. Pourquoi Mandriva ne le fait JAMAIS ?
On voit quoi dans ce journal ? On voit que Mandriva et TurboLinux vont travailler "main dans main" pour rpm. Pourquoi ce n'est pas possible avec .rpm.org (ou Fedora) ?
[^] # Re: mini-forks
Posté par IsNotGood . Évalué à 3.
Longtemps Fedora/Red Hat n'a pas utilisé rpmlint. Puis vers FC3 Fedora a commencé à utiliser rpmlint (projet Mandriva).
Fedora n'a pas "forcké" rpmlint pour ses besoins.
Un rapide grep sur le changelog (Ville Skyttä est un développeur Fedora depuis longtemps, je ne sais pas s'il est employé Red Hat) :
$ grep "Ville Skyttä" * | wc -l
105
$ grep "mandriva" * | wc -l
326
Joli alors Ville Skyttä ne participe que depuis 2006.
Les bugs sont renvoyés en upstream et corrigés en upstream :
https://bugzilla.redhat.com/show_bug.cgi?id=244835
Il n'y a pas de correction locale.
Pourquoi Mandriva ne fait pas ça ? Ou si peu.
[^] # Re: mini-forks
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
Parce que Ville (qui n'est pas employé RH à ma connaissance) a eu direct le droit de commit dans rpmlint alors que les gens de chez Mandriva se sont plutôt fait ignorer pendant des années quand ils ont voulu participer ?
Mais bon ce cas est spécial, rpmlint a été sorti de chez Mandriva il y a je crois 2 ans, et est hebergé maintenant sur zarb.org, ou Ville (et d'autres gens de rh et de suse) ont deja des comptes pour jpackage.
Il a droit de commit et donc corrige directement upstream c'est sur que c'est plus facile.
Je corrige aussi mes bugs upstream à chaque fois que je peux, c'est plus simple, mais quand upstream se fout d'un problème, ben le patch reste chez nous et on doit se taper de le maintenir...
[^] # Re: mini-forks
Posté par IsNotGood . Évalué à -1.
Es-ce que tu peux donner des preuves de ça ?
Un rapport de bug, etc...
Parceque Red Hat a une participation quasi massive en upstream. Si c'était des porcs, ça se saurait. Tu ne crois pas.
Parce ton commentaire frize le FUD et rien d'autre.
Moi j'argumente. Insufisament, très probablement. Mais je ne sors pas des trucs de mon chapeau.
[^] # Re: mini-forks
Posté par IsNotGood . Évalué à 1.
Il a fait la démarche de le demander et prouvé sa valeur. Ce qui est bien normal.
Faites de même avec Fedora. Il y a plein plein de cvs Red Hat qui ne sont pas en rw uniquement pour les employés de Red Hat.
En passant, le nouveau "patron" Fedora, n'est pas un employé Red Hat.
Red Hat est passé de up2date à yum et yum n'a pas été développé par Red Hat. Toute l'infrastructure de Fedora a vu la participation massive de développeurs non Red Hat (communauté, Dell, IBM, etc). Le site fedoraproject.org n'est pas géré par Red Hat.
Etc.
Red Hat/Fedora est beaucoup plus ouvert que tu ne le crois. Mais pas ouvert à n'importe quoi.
[^] # Re: mini-forks
Posté par Pascal Terjan (site web personnel) . Évalué à 10.
Quasiment jamais.
Lorsque vous faites des modifs, en discutez vous avec l'upstream (qui ici est manifestement le mkinitrd de Fedora) ?
Ben non.
Pendant des années les tentatives de remontées vers RedHat ont été ignorées (je me souviens de la joie quand un patch Mandriva était pris chez RedHat, et d'un patch important sur mkinitrd resté sans commentaires sur le bugzilla pendant plus 'un an...). Ca justifie d'avoir forké pour avoir un truc qui marche.
De nos jours la collaboration avec Fedora est bcp plus facile qu'elle ne l'était avec RedHat, et il y a donc retour vers les versions Fedora.
Que pouvez vous avoir pour udev qui est vous est utile et ne l'est pas aux autres ?
Au hasard, des noms de groupe auxquels donner certains devices qui ne sont pas les mêmes que chez d'autres ?
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).
C'est faux, on a depuis de nombreuses années la ldetect. De nos jours elle est moins utile car le noyau decrit bien ce qui est geré par quel module, mais reste utile dans pas mal de cas.
De plus tout n'est pas dans le noyau, et il faut être capable de detecter quels rpm supplementaires installer en fonction du materiel, ou savoir si on est sur un portable par exemple.
Mandriva pourrait en discuter upstream. Pourquoi Mandriva ne le fait JAMAIS ?
C'est tout simplement faux. Certains le font plus continuellement que d'autres (je pense par exemple à Fred Crozat pour tout ce qui est GNOME/hal/...) mais globalement tout le monde essaye d'être le plus proche d'upstream, ca fait moins de boulot et travailler à plusieurs permet que ca marche mieux pour tout le monde...
[^] # Re: mini-forks
Posté par IsNotGood . Évalué à -1.
Oui. Mais il ne faut pas généraliser.
> 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.
> C'est faux, on a depuis de nombreuses années la ldetect.
Ben ça doit être fabuleux par rapport à ce que fait le noyau et hal...
Vous allez aussi forcker hal ?
> De plus tout n'est pas dans le noyau, et il faut être capable de detecter quels rpm supplementaires installer en fonction du materiel, ou savoir si on est sur un portable par exemple.
Ce qui n'est plus de la détection de matériel. C'est du paramétrage en fonction du matériel qui a déjà été détecté (les modules ont été chargés et donc le matériel a été détecté). C'est seulement listé le matériel détecté.
> C'est tout simplement faux. Certains le font plus continuellement que d'autres (je pense par exemple à Fred Crozat pour tout ce qui est GNOME/hal/...) mais globalement tout le monde essaye d'être le plus proche d'upstream, ca fait moins de boulot et travailler à plusieurs permet que ca marche mieux pour tout le monde...
OK. Mais je disais par rapport à des choses qui sont upstream chez Fedora (et plus généralement Red Hat) pour Mandriva.
Un petit exemple mkinitrd.
mkinitrd de Mandriva :
rpm -q --changelog -p mkinitrd-4.2.17-55mdv2008.1.src.rpm | grep -i merge
It probably should be just merged in label patch.
- merge rh 4.2.12
- merge bits from rh 4.1.12
- merge p1 into p0
- big merge from redhat's 4.1.9
- merge bits from redhat 3.5.24
- merge patch 5 into patch 0 (simplify patch)
- drop patch 4 (merged into simplified patch 0)
Les patchs Mandriva :
cat *.patch | diffstat | tail -1
10 files changed, 1944 insertions(+), 803 deletions(-)
Dans la version upstream (6.0.19), on ne trouve que ça :
find . -type f -print0 | xargs -0 grep -i mandr
./mkinitrd:# Guillaume Cottenceau <gc@mandrakesoft.com>
./mkinitrd.spec.in:- mkinitrd: add patch from gc@mandrakesoft.com to determine module
./mkinitrd.spec:- mkinitrd: add patch from gc@mandrakesoft.com to determine module
M'enfin, apparament tout est prétexte pour ne pas bosser avec Red Hat.
J'espère que vous aurez de meilleurs disposition d'esprit avec TurboLinux.
[^] # Re: mini-forks
Posté par blino . Évalué à 5.
> 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 IsNotGood . Évalué à 1.
Juste. Désolé. D'ailleur ça fait doublons avec /etc/makedev.d.
Je me suis mélangé les crayons.
> ConsoleKit/PolicyKit ne permettent que d'appliquer des ACLs aux devices
Très très bizarre.
[test@one /]$ ll dev/snd/pcmC0D1p
crw-rw----+ 1 root root 116, 4 jan 14 19:03 dev/snd/pcmC0D1p
[test@one /]$ id
uid=502(test) gid=502(test) groupes=502(test) context=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023
[test@one /]$ ll dev/snd/pcmC0D1p
crw-rw----+ 1 root root 116, 4 jan 14 19:03 dev/snd/pcmC0D1p
[test@one /]$ getfacl dev/snd/pcmC0D1p
# file: dev/snd/pcmC0D1p
# owner: root
# group: root
user::rw-
user:gdm:rw-
user:test:rw-
group::rw-
mask::rw-
other::---
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.
NB : c'est le début de l'utilisation de ConsoleKit.
> ils ne changent pas le groupe
Ici (F8) il ne change pas le groupe (du moins lorsque quelqu'un prend la console). Les groupes pour les périphérique, ce n'est pas la tasse de thée de Fedora. Il n'y a pas de groupe audio, video, etc chez Fedora.
> 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 :-)).
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).
Depuis longtemps je le vire de ma bécane (sans --force ou --nodeps !) et ça ne dérange rien.
[^] # Re: mini-forks
Posté par blino . Évalué à 3.
> 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 IsNotGood . Évalué à 0.
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
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).
[^] # Re: mini-forks
Posté par blino . Évalué à 5.
> 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.
# Précisions sur le forum mdv
Posté par Jean Roc Morreale . Évalué à 5.
- la gestion au quotidien est faite par mdv
- ce qui en sera issu sera sur le svn de mdv
- 4 devs de Turbolinux seront accueillis par mandriva
A priori, le fait d'avoir des devs sur place devraient améliorer un tantinet la communication, et in fine les chances d'aboutissement réel de ce projet. Enfin bon ça reste mandriva donc même dans un bureau à 2m des autres la com interne risque de foirer en chemin :p
[^] # Re: Précisions sur le forum mdv
Posté par IsNotGood . Évalué à -4.
Je doute que ce "lab" sera localisable géographiquement. Il n'est rien dit sur ce point.
http://www.mandriva.com/enterprise/fr/societe/presse/mandriv(...)
C'est "désespérant" de lire des trucs (pour ne pas dire conneries) pareils...
Moinsez moi, j'ai la flemme d'expliquer à quel point je trouve ça con.
[^] # Re: Précisions sur le forum mdv
Posté par Maclag . Évalué à 2.
D'autre part TurboLinux est quand même pas si mal placé sur le marché asiatique, donc tout bénéf pour aller à la chasse aux infos sur ce que les distribs "locales" proposent de plus que les autres.
Quant au «Ce partenariat stratégique est le premier pas vers la convergence des distributions Linux à base de RPM », ben je dirais que c'est pas la première fois qu'on se la pète un peu en région parisienne... :D
Il oublie juste de préciser "distributions Linux à base de RPM hors Redhat, Suse, et forks associés"...
Bref, "attendez et voyez"!
[^] # Re: Précisions sur le forum mdv
Posté par IsNotGood . Évalué à 1.
Tout à fait d'accord (sauf pour IBM).
[^] # Re: Précisions sur le forum mdv
Posté par imr . Évalué à 2.
> Tout à fait d'accord (sauf pour IBM).
Exact, IBM étant le seul poids lourd de la phrase initiale.
[^] # Re: Précisions sur le forum mdv
Posté par Maclag . Évalué à 1.
Euh... OK!
Mais tout est relatif hein! Je crois que ça ferait plaisir à Mandriva d'être "aussi petit" qu'un RedHat ou un Novell, z'avez qu'à virer le IBM pour que ça passe mieux!
[^] # Re: Précisions sur le forum mdv
Posté par imr . Évalué à 4.
Voila ma vraie réponse: on peut bosser avec un poids lourd, tout dépend des conditions.
Mandriva a déjà travaillé et passé des accords avec des poids lourds comme HP et Intel.
De l'autre coté, Suse était dépendante de IBM pour son financement, et a du se vendre à Novell, le rachat étant monté par IBM. Pour finir par se retrouver embringuer dans du mono et des accords avec microsoft. bof.
Donc tout dépend des circonstances et de l'accord, ce n'est pas une question de taille. :)
En ce qui concerne cet accord, j'aime l'idée de mutualiser des ressources, j'aime l'idée de préserver son indépendance et sa spécificité culturelle, j'aime mandriva et j'aime la culture japonaise, donc il me met des étoiles pleins les yeux, j'ai bien peur de ne pas pouvoir le percevoir tel qu'il est vraiment. :)
Je pense que United Linux mettait la barre trop haut et que cet accord vient de l'analyse de cet échec : vouloir avoir des distros s'entendre sur une distro commune et se rendre compte au bout qu'elles avaient toutes une idée différente de ce que doit être cette distro, ça ne me semble pas une surprise.
Maintenant, travailler ensemble par exemple sur un même kernel (qu'on peut toujours customiser localement) ça me semble concrét et réaliste donc réalisable, et en théorie ça permettra plus de remontées upstream.
Surtout qu'on passe aux versions répandues communément utilisées de ces sous systèmes, par volonté de ne plus rester dans notre coin à réinventer la roue.
A partir de là, on verra bien si d'autres distros plus grosses sont prêtes à coopérer avec des plus petites dans un but d'améliorer les logiciels en question comme elles le clament ou si finalement, elles n'ont qu'une attitude prédatrice comme les autres boites proprios.
Et sinon, pour l'autres aspect de ton commentaire, tout fait d'accord avec toi, tisser des liens et des alliances avec l'Asie et le Japon en particulier, c'est important et une très bonne chose.
[^] # Re: Précisions sur le forum mdv
Posté par Maclag . Évalué à 1.
T'excuse pas, y'a pas de quoi!!
Surtout que je partage pas mal ton analyse!
[^] # Re: Précisions sur le forum mdv
Posté par IsNotGood . Évalué à 2.
Pas vraiment lié.
IBM est un "généraliste". Il propose des solutions avec n'importe quel OS et dont du GNU/Linux. Si IBM a Mandriva comme partenaire privilégié, IBM vendra du Mandriva, commandera des développements à Mandriva, etc.
De plus ça "ouvre" l'immense carnet d'adresse d'IBM.
[^] # Re: Précisions sur le forum mdv
Posté par Prae . Évalué à 2.
Bah, déjà que la communation a parfois du mal à passer entre étage ... ;-)
Aie! non! patapé ... je sors --->[]
# bonne initiative
Posté par papap . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.