Une image de CD de démarrage est fournie sur la clé USB.
Cette image charge le même initrd que celui que grub chargerait par un démarrage depuis la clé, la clé USB y sera ensuite montée par label.
Ce n'est pas parce que c'est une solution "clef en main" que cela nécessite une nouvelle distribution. Ce n'est pas impossible (ni difficile) à intégrer dans une distribution comme Ubuntu.
Les quelques adaptations de scripts peuvent probablement être fusionnées dans les paquetages Ubuntu correspondants, en les rendant plus configurables si besoin.
Plus sérieusement, l'idée d'avoir une distribution adaptée aux cyber-cafés est intéressante, mais est-ce que ça nécessite vraiment une nouvelle distribution ?
La profusion de systèmes basés sur Ubuntu porte à confusion, c'est difficile de répondre à des besoins un peu plus évolués en devant choisir parmi un essaim de distributions spécialisées chacune dans une tâche précise. Et cela entraîne (probablement) des coûts de maintenance supplémentaires assez importants.
Pourtant, il serait possible de fournir pour chaque orientation de tâche un meta-paquetage qui installe les paquetages nécessaires et procède à la pré-configuration. Tout ceci avec une complexité supplémentaire quasi-nulle, la sélection d'un paquetage pendant l'installation étant triviale et facilement automatisable.
Qu'est-ce qui justifie cette orientation ? Un max de buzz en plus avec une visibilité accrue pour Ubuntu ? Merci la Ubuntu Marketing Team \o/
Bravo quand même pour OS-Café, et bonne continuation !
Notre outil de configuration et nos scripts ucarp permettent d'utiliser l'option preempt d'ucarp, qui permet de démarrer ucarp en mode maître. Cette option doit être activée dans tous les fichiers de configurations /etc/ucarp.d de la machine maître par défaut.
-P --preempt
Turn on preemptive failover. This causes an instance of ucarp to
take over master status right away.
Parmi les machines faisant partie de l'ensemble de redondance, l'une d'elle uniquement doit être configurée de cette façon, mais c'est à l'administrateur de le vérifier.
Pour le cas où un lien seulement tombe, le plus difficile est de détecter si la panne est bien du coté maître. Peut-être qu'on peut le supposer si un ping broadcast ARP sur l'interface en question ne retourne pas de réponses de voisins. Je ne me suis pas vraiment penché sur la question, peut-être que l'équipe responsable des composants kernels et des tests à un avis plus forgé sur la question.
Oui, il est possible de surveiller toutes les interfaces.
Par contre, dans le cas où une seule interface tombe sur la machine, le basculement en mode maître d'ucarp ne s'effectue que pour l'interface qui tombe.
Pour l'instant, le principal cas de récupération est celui où toute une machine maître tombe, ce qui fait que toutes les interfaces de la machine escale sont basculées en mode maître.
Le cas où un lien physique (et pas une machine entière) tombe, c'est plus difficile à gérer. Si la machine est maître, il faut déjà s'assurer que c'est le lien physique de cette machine qui est tombé. Si c'est le cas, il faudrait pouvoir notifier les autres démons ucarp de la même machine de passer en mode esclave, avec des signaux par exemple.
Je précise que je ne suis pas le seul à avoir fait tout ça, je suis juste l'implémenteur de l'interface finale. Ça a quand même nécessité beaucoup de tests de configuration et de mise en place de la part de nos équipes kernel et QA, et si le résultat paraît si concis, c'est en grande partie grâce à eux :-)
Il n'y a rien d'extraordinaire, il s'agit surtout d'un travail d'intégration.
Des fichiers de configuration se trouvent dans /etc/ucarp.d pour chaque interface en failover, ils déterminent les options passées à ucarp.
Le service ucarp lance un ucarp par interface configurée, et le service ct_sync charge le module avec les options de /etc/sysconfig/ucarp. Les deux services sont distincts pour pouvoir faire simplement du failover d'interface sans redondance de firewall.
Un script commun ucarp-action.sh est lancé quand ucarp change d'état, il permet de basculer l'adresse IP et de devenir maître pour ct_sync (si configuré).
Je devrai écrire tout ça sur le wiki, avec un peu plus de doc, quand j'aurai un moment.
Les lecteurs mal inspirés pourront troller sur le fait que le développement est fait dans tous le sens sur nos gestionnaires de version, que le "build system" est éclaté, ou encore que les outils Perl utilisent une bibliothèque packagée chez Mandriva seulement (libre à eux de le packager).
Parce que ne pas connaitre blino, c'est possible.
Mais ne pas connaitre Warly, qui est LE Release Manager depuis des lustres chez mdv, c'est comme... voyons, quelle comparaison trouver ... ne pas savoir qui est notre ministre de l'intérieur futur président de la république.
Je vois pas ce que cette tafiole de Warly a de plus que moi ! (à part être mon chef)
Au fait, le patch incommplet en question a traîné plusieurs mois dans leur CVS, avant que Fedora ne passe à la RC il n'y a pas si longtemps.
Je me permet de dire que c'est un backport incomplet de plusieurs patches puisque je me suis penché sur la question pendant quelques heures, et qu'il contient un amas de commits de davidr et ajax, la plupart antérieurs à la date du patch, et quelques uns étant incomplets, c'est flagrant.
Le patch est quand même resté 5 mois dans leur package sans être complété, donc je crois pouvoir me permettre de dire que leur package Mesa "cassait" Xgl (même s'il ajoutati du support AIGLX).
Je vais m'arrêter là au sujet de ce patch :-)
Merci quand même à RedHat d'avoir lancé AIGLX
Le dév principal de Mandriva a été "simplement" l'écriture de scripts pour gérer simplement les interactions de ct_sync et d'ucarp sur plusieurs interfaces, et celle d'un frontend : http://people.mandriva.com/~blino/drakinvictus.png
On ne sait pas compris. Ce n'est pas Red Hat qui récupérait les patchs du CVS puisque c'est Red Hat qui a fait ce patch. Red Hat ne faisait pas de backport du CVS.
Ce serait le cas si RedHat testait directement le code dans Fedora, mais apparemment leur procédure est plutôt de faire accepter et appliquer upstream avant de l'intégrer dans leur package (ce qui est une bonne chose quand on a le temps).
Ce ne sont pas seulement des patchs d'Adam Jackson (Ajax) de Fedora, mais aussi des ajouts de David Reveman, de Novell.
Le patch de Fedora contenait quelques boulettes, comme le fait de modifier le prototype de glXBindTexImageEXT() pour le support d'attirbList, sans contenir l'implémentation réelle ...
Et même s'il ne faisait qu'un peu plus d'une centaine de lignes, c'est quand même une accumulation de paches incrémentaux du CVS (ce qui est normal, c'est bien de réduire autant que faire se peu la taille d'un commit). Cf les logs de http://webcvs.freedesktop.org/mesa/Mesa/src/glx/x11/glxcmds.(...)
par exemple.
Mais bon, je ne dénigre pas la contribution de RedHat au projet, c'est en grande partie grâce à eux que Mandriva peut mettre en avant les bureaux 3D.
C'est juste que leur packaging n'est pas forcément à la hauteur de ce qu'ils contribuent à Mesa/X, peut-être parce que le développement et le packaging ne sont pas faits par les mêmes personnes.
??? Il y a pratiquement rien comme patch dans le paquet mesa de Fedora.
Je parle notamment du patch mesa-6.5-texture-from-pixmap-fixes.patch, qu'ils ont trainé pendant des mois et qui était une accumulation mal triée de backports du CVS.
Il a été supprimmé lors du passage à Mesa 6.5.1 RC1 http://cvs.fedora.redhat.com/viewcvs/devel/mesa/mesa.spec?hi(...)
Il ne casse pas Xgl, il n'y a pas Xgl sous Fedora. Ce qui n'empêche pas certains d'utiliser <un serveur avec Xgl.
Le patch sus-cité n'était pas un backport complet, cassait quelques prototypes de fonctions, et le patch mesa-6.5-tfp-fbconfig-attribs.patch ne contenait pas la partie glxext, ce qui empêchait d'utiliser Xgl.
Mais bon, puisque Fedora utilise une version de Mesa RC plus proche du CVS, les problèmes ont dû disparaitre.
Et il y a un "évènement" ! C'est la première distribution a supporter Mac sur i386 ! C'est un autre boulot a faire que de seulement mettre par défaut (AI)XGL et mettre en place une blacklist pour les carte qui ne supporte pas (AI)XGL.
Si c'était aussi simple que ça, toutes les distros l'auraient fait.
Mandriva est la première distro à intégrer un support des deux tehnologies AIGLX et Xgl, ce qui permet de couvrir un maximum de matériel.
Bien sûr, ce n'est pas le même travail de développer les technos que celui d'intégration dans une distrib, mais ce dernier n'est pas négligeable. Il a impliqué une sélection assez difficile de backports de Mesa, là où Fedora se contente de choisir d'appliquer des patches nécessaires à AIGLX, même s'ils cassent le support Xgl. L'outil que Mandriva propose n'est évidemment pas le résultat de mois de développement, mais on fait avec ce qu'on peut, Mandriva n'a pas une dizaine de développeurs à dédier à plein temps aux bureaux 3D.
> il y a également beaucoup de news sur Fedora, Ubuntu, Suse et Debian
C'est un blague ?
Non, il suffit de regarder http://linuxfr.org/sections/Distribution,1.html pour voir que Mandriva n'est pas du tout privilégiée, et qu'on y trouve plus d'articles sur Fedora cette année.
Il faut arrêter la parano à propos de Mandriva, même si c'est coutumier ici ...
Quasiment tout employé qui fait du libre est engagé au niveau de la communauté.
Les développeurs de logiciel libre sont souvent dans une communauté très spécialisée, et pas forcément dans une communauté plus généraliste comme linuxfr
Et bien vu que cette news est passé, on peut se poser des questions sur la sévérité de la modération lorsqu'il sagit de warly.
Les autres news pour d'autres distributions qui sont aussi intéressante que celle-la devrait aussi passer.
Oui, mais il faut déjà qu'elles soient proposées.
Et puis, certaines news moins importantes qu'une release candidate de distribution passent également, comme l'annonce d'une beta d'un installeur graphique (quelle grande première :-p)
Et tu trouves normal que Mandriva soit favorisé ici ?
Je ne vois pas vraiment de traitement de faveur pour Mandriva, il y a également beaucoup de news sur Fedora, Ubuntu, Suse et Debian
Tu trouves normal qu'un site d'information soit partiellement "noyauté" par Mandriva et ce sans en informer le lecteur ?
Ce n'est pas très intéressant de le préciser, vu que les modérateurs ont jugé le contenu correct. Que cette news soit écrite par warly ou des contributeurs Mandriva n'est pas très important.
Et ce n'est pas la première fois que linuxfr accèpte une news de ce "release manager". Mais seulement pour Mandrake/Mandriva. C'est bien de la publicité gratuite.
Et c'est mal de faire des annonces quand on travaille chez Mandriva ? C'est plutôt bon signe de voir un engagement des employés au niveau de la communauté, non ?
De plus, il me semble que les articles sont modérés, et que si c'était de la publi-information inintéressante, celui-ci ne serait pas passé.
Evidemment ! Le processus de QA est rigoureux et implique des tests intensifs pour arriver à un résultat impeccable. De plus, la communauté a dû se mobiliser pour amasser les high-scores, disponibles sur http://xmoto.free.fr/ (les meilleurs scores sont maintenant disponibles depuis le jeu, qui va les récupérer en ligne, merci Nicolas \o/)
Après avoir été la killer-feature du Mandriva Club, puis de Mandriva Kiosk, xmoto reste la fonctionnalité la plus attendue dans Mandriva Linux 2007.0, et nous mettons tout en oeuvre pour que personne ne soit déçu.
[^] # Re: Boot USB ?
Posté par blino . En réponse à la dépêche Un bureau 3D dans la poche !. Évalué à 5.
[^] # Re: Boot USB ?
Posté par blino . En réponse à la dépêche Un bureau 3D dans la poche !. Évalué à 10.
Cette image charge le même initrd que celui que grub chargerait par un démarrage depuis la clé, la clé USB y sera ensuite montée par label.
D'ailleurs, les questions fréquentes sur Mandriva Flash sont énumérées ici (avec leurs réponses, s'il est besoin de préciser) :
http://www.mandriva.com/fr/individuals/products/flash/faq
[^] # Re: (HS) Encore une autre Ubuntu
Posté par blino . En réponse à la dépêche Sortie de la solution Os-Café 0.9. Évalué à 3.
Les quelques adaptations de scripts peuvent probablement être fusionnées dans les paquetages Ubuntu correspondants, en les rendant plus configurables si besoin.
# (HS) Encore une autre Ubuntu
Posté par blino . En réponse à la dépêche Sortie de la solution Os-Café 0.9. Évalué à 5.
Plus sérieusement, l'idée d'avoir une distribution adaptée aux cyber-cafés est intéressante, mais est-ce que ça nécessite vraiment une nouvelle distribution ?
La profusion de systèmes basés sur Ubuntu porte à confusion, c'est difficile de répondre à des besoins un peu plus évolués en devant choisir parmi un essaim de distributions spécialisées chacune dans une tâche précise. Et cela entraîne (probablement) des coûts de maintenance supplémentaires assez importants.
Pourtant, il serait possible de fournir pour chaque orientation de tâche un meta-paquetage qui installe les paquetages nécessaires et procède à la pré-configuration. Tout ceci avec une complexité supplémentaire quasi-nulle, la sélection d'un paquetage pendant l'installation étant triviale et facilement automatisable.
Qu'est-ce qui justifie cette orientation ? Un max de buzz en plus avec une visibilité accrue pour Ubuntu ? Merci la Ubuntu Marketing Team \o/
Bravo quand même pour OS-Café, et bonne continuation !
[^] # Re: Netinstall
Posté par blino . En réponse à la dépêche Sortie de Zod (alias Fedora Core 6). Évalué à 2.
[^] # Re: ...
Posté par blino . En réponse au journal Mandriva veut raccourcir le cycle de sortie à 6 ou 4 mois. Évalué à 9.
[^] # Re: quelle enfilade !
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 2.
Parmi les machines faisant partie de l'ensemble de redondance, l'une d'elle uniquement doit être configurée de cette façon, mais c'est à l'administrateur de le vérifier.
Pour le cas où un lien seulement tombe, le plus difficile est de détecter si la panne est bien du coté maître. Peut-être qu'on peut le supposer si un ping broadcast ARP sur l'interface en question ne retourne pas de réponses de voisins. Je ne me suis pas vraiment penché sur la question, peut-être que l'équipe responsable des composants kernels et des tests à un avis plus forgé sur la question.
[^] # Re: quelle enfilade !
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 2.
Par contre, dans le cas où une seule interface tombe sur la machine, le basculement en mode maître d'ucarp ne s'effectue que pour l'interface qui tombe.
Pour l'instant, le principal cas de récupération est celui où toute une machine maître tombe, ce qui fait que toutes les interfaces de la machine escale sont basculées en mode maître.
Le cas où un lien physique (et pas une machine entière) tombe, c'est plus difficile à gérer. Si la machine est maître, il faut déjà s'assurer que c'est le lien physique de cette machine qui est tombé. Si c'est le cas, il faudrait pouvoir notifier les autres démons ucarp de la même machine de passer en mode esclave, avec des signaux par exemple.
[^] # Re: quelle enfilade !
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 2.
[^] # Re: Mandriva et la politique qualité
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 2.
[^] # Re: quelle enfilade !
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 6.
Les scripts intéressants se trouvent ici :
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/i(...)
http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/ucarp/
http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/drakx/trunk/(...)
http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/drakx/trunk/(...)
Il n'y a rien d'extraordinaire, il s'agit surtout d'un travail d'intégration.
Des fichiers de configuration se trouvent dans /etc/ucarp.d pour chaque interface en failover, ils déterminent les options passées à ucarp.
Le service ucarp lance un ucarp par interface configurée, et le service ct_sync charge le module avec les options de /etc/sysconfig/ucarp. Les deux services sont distincts pour pouvoir faire simplement du failover d'interface sans redondance de firewall.
Un script commun ucarp-action.sh est lancé quand ucarp change d'état, il permet de basculer l'adresse IP et de devenir maître pour ct_sync (si configuré).
Je devrai écrire tout ça sur le wiki, avec un peu plus de doc, quand j'aurai un moment.
Les lecteurs mal inspirés pourront troller sur le fait que le développement est fait dans tous le sens sur nos gestionnaires de version, que le "build system" est éclaté, ou encore que les outils Perl utilisent une bibliothèque packagée chez Mandriva seulement (libre à eux de le packager).
[^] # Re: Mandriva et la politique qualité
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 7.
Je vois pas ce que cette tafiole de Warly a de plus que moi ! (à part être mon chef)
[^] # Re: Mandriva et la politique qualité
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 3.
Je me permet de dire que c'est un backport incomplet de plusieurs patches puisque je me suis penché sur la question pendant quelques heures, et qu'il contient un amas de commits de davidr et ajax, la plupart antérieurs à la date du patch, et quelques uns étant incomplets, c'est flagrant.
Le patch est quand même resté 5 mois dans leur package sans être complété, donc je crois pouvoir me permettre de dire que leur package Mesa "cassait" Xgl (même s'il ajoutati du support AIGLX).
Je vais m'arrêter là au sujet de ce patch :-)
Merci quand même à RedHat d'avoir lancé AIGLX
[^] # Re: quelle enfilade !
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 4.
[^] # Re: Passez à Fedora
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 3.
[^] # Re: Mandriva et la politique qualité
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 1.
Ce serait le cas si RedHat testait directement le code dans Fedora, mais apparemment leur procédure est plutôt de faire accepter et appliquer upstream avant de l'intégrer dans leur package (ce qui est une bonne chose quand on a le temps).
[^] # Re: Mandriva et la politique qualité
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 5.
Le patch de Fedora contenait quelques boulettes, comme le fait de modifier le prototype de glXBindTexImageEXT() pour le support d'attirbList, sans contenir l'implémentation réelle ...
Et même s'il ne faisait qu'un peu plus d'une centaine de lignes, c'est quand même une accumulation de paches incrémentaux du CVS (ce qui est normal, c'est bien de réduire autant que faire se peu la taille d'un commit). Cf les logs de http://webcvs.freedesktop.org/mesa/Mesa/src/glx/x11/glxcmds.(...)
par exemple.
Mais bon, je ne dénigre pas la contribution de RedHat au projet, c'est en grande partie grâce à eux que Mandriva peut mettre en avant les bureaux 3D.
C'est juste que leur packaging n'est pas forcément à la hauteur de ce qu'ils contribuent à Mesa/X, peut-être parce que le développement et le packaging ne sont pas faits par les mêmes personnes.
[^] # Re: Mandriva et la politique qualité
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 4.
Je parle notamment du patch mesa-6.5-texture-from-pixmap-fixes.patch, qu'ils ont trainé pendant des mois et qui était une accumulation mal triée de backports du CVS.
Il a été supprimmé lors du passage à Mesa 6.5.1 RC1
http://cvs.fedora.redhat.com/viewcvs/devel/mesa/mesa.spec?hi(...)
Le patch sus-cité n'était pas un backport complet, cassait quelques prototypes de fonctions, et le patch mesa-6.5-tfp-fbconfig-attribs.patch ne contenait pas la partie glxext, ce qui empêchait d'utiliser Xgl.
Mais bon, puisque Fedora utilise une version de Mesa RC plus proche du CVS, les problèmes ont dû disparaitre.
[^] # Re: Mandriva et la politique qualité
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 3.
Si c'était aussi simple que ça, toutes les distros l'auraient fait.
Mandriva est la première distro à intégrer un support des deux tehnologies AIGLX et Xgl, ce qui permet de couvrir un maximum de matériel.
Bien sûr, ce n'est pas le même travail de développer les technos que celui d'intégration dans une distrib, mais ce dernier n'est pas négligeable. Il a impliqué une sélection assez difficile de backports de Mesa, là où Fedora se contente de choisir d'appliquer des patches nécessaires à AIGLX, même s'ils cassent le support Xgl. L'outil que Mandriva propose n'est évidemment pas le résultat de mois de développement, mais on fait avec ce qu'on peut, Mandriva n'a pas une dizaine de développeurs à dédier à plein temps aux bureaux 3D.
Non, il suffit de regarder http://linuxfr.org/sections/Distribution,1.html pour voir que Mandriva n'est pas du tout privilégiée, et qu'on y trouve plus d'articles sur Fedora cette année.
Il faut arrêter la parano à propos de Mandriva, même si c'est coutumier ici ...
[^] # Re: Mandriva et la politique qualité
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 5.
Les développeurs de logiciel libre sont souvent dans une communauté très spécialisée, et pas forcément dans une communauté plus généraliste comme linuxfr
D'après http://linuxfr.org/~warly/news.html , ses news ne sont pas si fréquentes que ça...
Oui, mais il faut déjà qu'elles soient proposées.
Et puis, certaines news moins importantes qu'une release candidate de distribution passent également, comme l'annonce d'une beta d'un installeur graphique (quelle grande première :-p)
Je ne vois pas vraiment de traitement de faveur pour Mandriva, il y a également beaucoup de news sur Fedora, Ubuntu, Suse et Debian
Ce n'est pas très intéressant de le préciser, vu que les modérateurs ont jugé le contenu correct. Que cette news soit écrite par warly ou des contributeurs Mandriva n'est pas très important.
[^] # Re: Mandriva et la politique qualité
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 9.
Et c'est mal de faire des annonces quand on travaille chez Mandriva ? C'est plutôt bon signe de voir un engagement des employés au niveau de la communauté, non ?
De plus, il me semble que les articles sont modérés, et que si c'était de la publi-information inintéressante, celui-ci ne serait pas passé.
</avis d'un autre méchant dév Mandriva>
[^] # Re: trop fort XGL !
Posté par blino . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 4.
[^] # Re: xmoto
Posté par blino . En réponse à la dépêche Mandriva Linux 2007 Alpha (Frige) est disponible. Évalué à 10.
Après avoir été la killer-feature du Mandriva Club, puis de Mandriva Kiosk, xmoto reste la fonctionnalité la plus attendue dans Mandriva Linux 2007.0, et nous mettons tout en oeuvre pour que personne ne soit déçu.
[^] # Re: OpenGL
Posté par blino . En réponse à la dépêche Première version publique de ManiaDrive (1.01). Évalué à 3.
[^] # Re: draklive
Posté par blino . En réponse à la dépêche Mandriva One : testez-la. Évalué à 4.
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/gi/tools/draklive
Quant à UnionFS, il permet de faire de la superposition (overlay) de systèmes de fichiers :
http://www.fsl.cs.sunysb.edu/project-unionfs.html
http://www.unionfs.org/