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
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.
Posté par blino .
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.
>> 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.
Posté par blino .
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 ?
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.
Posté par blino .
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).
Posté par blino .
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.
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é.
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
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.
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.
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.
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
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)
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 ...
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.
[^] # Re: Superbe distrib
Posté par blino . 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 blino . 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 blino . 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 blino . En réponse au journal Manbo-Labs. É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 blino . En réponse au journal Manbo-Labs. É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.
[^] # Re: mini-forks
Posté par blino . En réponse au journal Manbo-Labs. É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 blino . En réponse au journal Manbo-Labs. É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: Restauration de la Mandriva Flash
Posté par blino . En réponse à la dépêche Monkey Studio, Gogh Project et 2008 Mandriva Flash 4GB. Évalué à 8.
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 blino . En réponse à la dépêche Des jeux pour GNU/Linux. Évalué à 3.
[^] # Re: Du côté de Mandriva :
Posté par blino . En réponse à la dépêche Des jeux pour GNU/Linux. Évalué à 3.
[^] # Re: Tempérer la nouvelle
Posté par blino . En réponse à la dépêche Dell choisit Ubuntu pour ses PC. Évalué à 5.
Mandriva héberge des forums gratuits sur le Club : http://forum.club.mandriva.com/
La doc est disponible sous forme de paquetages dans la distribution, ainsi que sur le site web de Mandriva.
Les mises à jour sont publiques, et disponibles facilement depuis l'applet de notification de mise à jour (désormais gratuite elle aussi)
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 blino . En réponse à la dépêche Dell choisit Ubuntu pour ses PC. Évalué à 10.
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 blino . En réponse à la dépêche Ubuntu 7.04 : le faon est sur ses pattes. Évalué à -2.
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.
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".
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 blino . En réponse au journal Sortie de la Mandriva Spring 2007.1. Évalué à 3.
Ça plaira surtout au troisième étage de la rue d'Aboukir !
[^] # Re: CINES
Posté par blino . En réponse au journal Lettre ouverte de Bancilhon. Évalué à 4.
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 blino . En réponse au journal Lettre ouverte de Bancilhon. Évalué à 4.
[^] # Re: Re:
Posté par blino . En réponse au journal A propos des draketools. Évalué à 4.
(ce serait plutôt "drakx")
drakwizard ?
[^] # Re: Qu'est-ce que tu veux
Posté par blino . En réponse au journal A propos des draketools. Évalué à 5.
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 blino . En réponse au journal Metisse dans mandriva!. Évalué à 4.
http://lists.lri.fr/pipermail/metisse/2007-January/000133.ht(...)
[^] # Re: excellent !
Posté par blino . En réponse au journal Metisse dans mandriva!. Évalué à 3.
[^] # Re: et bientot dans votre Cooker prés de chez vous
Posté par blino . En réponse au journal Le client second life passe en gpl. Évalué à 5.
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 blino . En réponse à la dépêche Un bureau 3D dans la poche !. Évalué à 2.
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 blino . En réponse à la dépêche Un bureau 3D dans la poche !. Évalué à 4.
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.
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, ...
Et le service harddrake est dans Mandriva depuis plus de 4 ans.
Merci, mais je sais très bien ce que j'ai développé pour Mandriva One et Mandriva Flash ...
[^] # Re: bonne phrase !
Posté par blino . En réponse à la dépêche Un bureau 3D dans la poche !. Évalué à 2.
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 blino . En réponse à la dépêche Un bureau 3D dans la poche !. Évalué à 7.
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.