L'objet du journal est de parler des plateformes l10n et plus particulièrement de Transifex et pas des outils permettant de traiter les fichiers de traductions.
Comme tu l'as souligné, les outils pour traiter les fichiers de traduction sont relativement éprouvés, gettext fournit un mode emacs, mais il y a des outils plus user-friendly comme kBabel (qui est assez populaire parmi les traducteurs de FedoraProject), gtranslator etc ...
Le gros problème des traducteurs se résume principalement à un mot: "collaboration".
Collaboration entre traducteurs, collaboration traducteur/développeur, collaboration distribution/upstream etc ....
FedoraProject utilisait Damned Lies pour gérer les traductions, le problème est DL dépends des outils GNOME (intltool et gnome-doc-utils), pas très pratique pour collaborer avec d'autres projets.
C'est là que Transifex intervient, il réalise une abstraction du VCS utilisé, il peut utiliser le système d'authentification du projet, les fichiers sont directement envoyé aux projets upstream contrairement à Rosetta donc pas de doublons.
Dans Rosetta, soit le projet est hébergé par Launchpad (sapusaipalibre), soit on importe le projet que l'on veut traduire, et dans ce dernier cas, on duplique l'effort de traduction, il faut fusionner à la main. Bref c'est un bordel sans nom, et la collaboration entre les traducteurs est nulle.
Transifex offre un seul et unique point d'entrée pour le traducteur, il s'inscrit et permettant de créer une communauté de traducteurs à la disposition des projets inscrits. Pour beaucoup de petits projets qui ont du mal à trouver des traducteurs, c'est une aubaine.
L'écriture de ces 2 articles n'est pas anodine, Matthew Garrett a été embauche par RedHat fin mars pour travailler sur l'aspect gestion d'énergie dans Linux.
D'ailleurs, je recommande la lecture des billets précédents qui sont tout aussi intéressants autour ce sujet (ACPI, interaction pilotes graphiques/gestion d'énergie)
Tout les composants ne t'assurent pas de compatibilité totale: que ce soit source, ABI (récemment Gecko 1.8 -> Gecko 1.9) ou comportemental.
Même dans GNOME, certains modules ne sont pas garantis comme étant stable au niveau de l'API ou de l'ABI, par exemple GStreamer.
Dans la mesure du possible, on évite de tout casser mais parfois tu n'as pas le choix.
> Tu peux synchroniser les versions de composantes sans forcément scléroser les projets, ce sont deux choses distinctes.
Tu te trompes à ce sujet. Si tu décides que les distributions majeures utiliseront le même noyau, le même X, le même GCC, les constructeurs se borneront à supporter ces versions et point barre.
Si tu cales ton cycle de développement sur celui des pilotes/logiciels propriétaire, tu es foutu. Si un constructeur refuse de supporter tel ou tel version du noyau ou de Xserver, tu fais quoi? selon Mark S., soit je fige mon interface pour lui faire plaisir, soit je fous des gros hacks pourris pour contourner ça.
C'est ce que faisait XGL ou Beryl avec les pilotes propriétaires, au fur et à mesure des hacks, la situation est devenu inmaintenable.
Au final, c'est AIGLX qui a gagné parce qu'ils ont préféré faire les choses proprement et qu'ils ont obligé les constructeurs à adapter leurs pilotes. Idem pour Beryl qui a disparu au profit de Compiz.
La synchronisation n'est pas une mauvaise chose, mais il faut des objectifs communs, c'est ce que fait Eclipse, Freedesktop.org.
Mais ça ne peut pas marcher entre des distributions ayant des objectifs différents, avec un calendrier rigide sur 2 ans alors que la plupart des logiciels libres n'ont pas une vision claire de ce que sera leur avenir au-delà de 6mois/1 an.
ça ne peut par marcher, si on joue dans un rapport de force entre distributions/upstream.
Si il doit avoir synchronisation, elle doit se faire en upstream et pas ailleurs.
> la facilité offerte aux développeurs de solutions propriétaires serait également offerte aux développeurs du libre.
Justement, le logiciel libre n'a pas besoin de cette facilité. Quand on casse une interface dans le noyau ou dans X, les pilotes sont quasi automatiquement corrigés que ce soit par le mainteneur du pilote, du changement d'API, ou un tiers.
G. K-H explique très bien pourquoi une API interne stable dans Linux n'a pas de sens et n'est pas souhaitable.
C'est même un argument majeur pour libérer les pilotes, les boites propriétaires n'ont guère le choix, soit elles fournissent un effort supplémentaire pour suivre les développements, soit elles libérent les informations. Sur le long terme, seule la seconde solution est viable.
Ce que tu appelles difficulté est en fait une force du libre, à tout moment, si un composant n'est pas satisfaisant, je peux le remplacer sans avoir à me retenir.
Si tu prends Gnome-vfs, c'était une merde en pourriture, plus personne n'osait y toucher. En moins de 6 mois, on a pu écrire un remplaçant gvfs -avec une meilleure architecture- et modifier tout gnome afin d'utiliser celui-ci.
Aurait-il été de possible de faire de même si on devait se soucier de la compatibilité ? si on ne pouvait pas modifier le code librement ?
> c'est une perte de ces différences qui seraient préjudiciables aux projets qui seraient délaissés par toutes les distributions participant.
Si on poussait la logique jusqu'au bout, effectivement, on aurait une espèce de méta-distribution avec des différences mineures.
C'était envisageable dans le cadre des distributions dérivées de Debian mais ça ne l'est pas au niveau des distributions GNU/Linux.
On n'est pas encore à ce stade, hein.
Mais ce qui arriverait, si les distributions majeures acceptaient cette proposition de figer les composants majeurs. Aujourd'hui, le nombre de pilotes propriétaire dans Linux est relativement restreint mais si on leur facilite la tâche, ils se multiplieront et on finira par ne plus pouvoir s'en passer. Et quand on sera tributaire des pilotes propriétaires, on sera poings et pieds liés.
On ne pourra plus corriger le noyau ou X ou du moins proprement si on a le malheur de casser un pilote.
Hein, il parle dans un second temps d'étendre ce concept au bureau, vous imaginez le jour ou il faudra faire de gros hacks pour ne pas casser MS Office Linux Edition parce que MS ne prévoit pas de mises à jour avant 3 ans.
On pouvait considérer le premier billet comme une intervention maladroite voire naïve mais là, il s'enfonce, c'est même dangereux ce qu'il propose.
The aim would be to encourage as much collaboration and discussion around component versions in the distributions, so that they can effectively exchange information and patches and bug reports.
Si toutes les distributions collaboraient un peu plus en upstream, ce serait inutile.
Si on doit partager des informations, des patchs et des rapports de bogues, ça doit être fait au niveau de l'upstream et uniquement à ce niveau-là.
ça n'empêche pas aux distributions d'avoir un espace d'échange pour partager leurs expérience au niveau du packaging, de l'intégration mais ça ne doit pas faire doublon avec l'upstream.
Some folks have said that my interest in this is “for Canonical”, or “just for Ubuntu”. And that’s really not true.
On y croit vachement.
I think it’s a much more productive approach for the whole free software ecosystem, and will help us compete with the proprietary world.
FOUTAISES ! Le but du logiciel libre est de fournir une alternative au logiciel propriétaire pas de l'affronter. ça c'est l'objectif des boites commerciales autour du libre que ce soit Canonical, RedHat, Novell etc... Les boites et le logiciel ont des intérêts communs mais nos objectifs ne sont pas les mêmes.
we’re more likely to have the same versions of key components at any given time.
C'est exactement ce qui lui a été proposé dans Debian Common Core et c'est exactement ce qu'il a refusé.
these are items which likely need the most stabilisation and testing before they ship to the innocent
C'est un travail de tout les jours, ce n'est pas en focalisant sur une version précise qu'on améliorera la situation. Pour cela, il n'y a pas de secret, il faut travailler en UPSTREAM.
I’ve talked with kernel developers who have said they would LOVE to know which kernel version is going to turn into RHEL or an Ubuntu LTS release, and ideally, they would LOVE it if those were the same versions, because it would enable them to plan their own work accordingly. So let’s do it!
On voudrait des noms, parce qu'à part les éventuels développeurs noyaux employés par Canonical j'y crois pas un instant.
Si il est capable de citer les personnes qui ne sont pas d'accord avec lui, il peut très bien faire l'inverse.
we would be able to improve greatly ALL of their support for today’s hardware
C'est le truc qui m'a le plus énervé. En gros, son but est de stabiliser les gros composants des principales distributions pour faciliter le support des pilotes propriétaires.
Alors que la communauté du logiciel libre se bat pour la libération des specs et des pilotes, Mark Shuttleworth lui enfonce un poignard dans le dos.
Et après, il ose dire qu'il soutient le logiciel libre ? Autant ce discours est compréhensible dans la bouche d'un chef d'entreprise, autant c'est inadmissible de la part d'un libriste.
Favoriser les pilotes propriétaires ne feront pas et ne feront jamais avancer le logiciel libre, ça peut favoriser les affaires d'une boite commerciale à un moment donné mais basta.
Mark S. nous propose un modèle propriétaire, seuls les composants sélectionné par les "boites" auront un support matériel correct, les autres devront marcher au pas.
Les constructeurs ne supporteront que les composants sélectionnés (les autres iront se faire foutre), les constructeurs n'auront pas envie de changer de politique vis à vis des pilotes libres (après tout, ça marcherait bien comme ça) ça reviendrait à faire un doigt aux autres plateformes libres (*BSD & cie), ils n'ont qu'à utiliser Linousque LTS (la fusion entre Ubuntu LTS, RHEL, etc ...)
Le pire c'est qu'il prévoit d'étendre ça à d'autres composants, c'est à dire à plus moins long terme, la sclérose de GNU/Linux, Il ne faudra plus casser les pilotes et logiciels propriétaires, bref, on finira comme Windows, une plateforme fade et sans innovation, trainant de gros boulets.
>ya tout un tas de truc qu'ils releasent aussi sans rien tester du tout, il comptent sur debian
C'est ce qui est arrivé avec le problème concernant le laptop-mode-tools dans Ubuntu, ils ont récupéré le paquet Debian sans vraiment regarder ce qu'il y avait dedans.
Mais comme tu dis, le problème est connu depuis longtemps mais aucune action concrète n'a été prise pour améliorer ce point.
On va retrouver l'erreur un peu partout.
Cette fois-ci, on s'est pris à la bourre pour écrire les annonces (il y a 2 versions), d'ailleurs je t'invite à la rédaction des annonces pour Fedora 10 si tu en as le temps (ça se passe sur la mailing-list fedora-fr), on aurait besoins de bons yeux comme les tiens ne serait-ce que pour relire le contenu. :)
> Côté SeLinux, notons que les utilisateurs commencent à être "confinés".
Xguest aurait effectivement pu avoir sa place dans l'annonce. ça fait partie des aspects méconnus de Fedora qui gagnerait à être mis en valeur.
Vu la double nature d'Ubuntu (distribution communautaire/commerciale), on peut attribuer deux sens au terme LTS. Ton analyse est tout à fait pertinente.
NéanmoinsMark Shuttleworth et Canonical n'hésitent pas à comparer Ubuntu LTS à RHEL ou Novell SuSE. Du moins, il y a une volonté de les concurrencer, comme l'indique le revirement stratégique de Canonical sur les serveurs, leur grille tarifaire (ils sont plus cher que RedHat à service plus ou moins égal). Le récent billet de Mark S. est suffisamment explicite à ce sujet.
Tu veux réunir dans un même endroit les meilleurs trolleurs du libres? RMS, Theo de Raadt, Linus Torvalds, ESR, Ulrich Drepper, Mark Shuttleworth &cie ?
On n'a pas besoin d'un deuxième championnat d'ultimate fighting. http://www.ufc.com/
Où est-ce que j'ai dit que WICD ne fonctionne pas?
J'ai juste dit que son installation ailleurs que sur une Ubuntu était pénible:
* pour l'utilisateur qui l'installe à partir des sources. T'as regardé le contenu de la tarball des sources?
* pour l'empaqueteur qui doit se faire chier à scripter l'installation et corriger les ubuntu-ismes dans le code.
Regarde la page concernant l'installation sur Fedora7 http://wicd.net/wiki/doku.php?id=fedora
Et encore, à l'époque où j'avais empaqueté le bousin, c'était pire encore. Vu le peu d'intérêt de l'upstream pour rendre leur machin portable sur d'autres distributions, je ne l'ai pas proposé dans FPC.
> La nous sommes d'accord, donc pour moi la seule solution 'correcte' aurait été de rester en FF2 pendant tous le cycle de support: c'est ce genre de chose que fait RHE..
Firefox 2 est en fin de vie, Ubuntu LTS est supporté pendant 3 ans pour la partie desktop. Cela signifie que Canonical aurait du maintenir seule Firefox 2 pendant près de 3 ans ou bien laisser s'accumuler les failles de sécurités, ce n'est pas clairement pas tenable pour eux.
Quant à RH, ils comptent inclure Firefox 3 dans RHEL 5.2 (actuellement en béta) et ce malgré qu'ils disposent d'une forte expertise dans le domaine (RH emploie pas mal de développeurs Mozilla et pas mal de développeurs Mozilla contribuent à Fedora). Mais avant de lâcher RHEL 5.2, celle-ci sera blindé de tests
Ce n'est pas tant le choix de FF3 qui est à remettre en question dans Ubuntu que la rigidité du calendrier (il aurait fallu décaler la sortie) et le problème récurrent dans la chaine de test.
Pour le premier, Mark Shuttleworth s'est encore plus enfoncé avec son dernier billet, quant au second, il faut embaucher une vraie équipe de testeurs y a pas 36000 solutions.
Il faudra probablement attendre Ubuntu 8.04.1 pour avoir une version digne du nom LTS.
On commence à être plus efficace, on a des bonnes relations avec les LUGs et les installs party sont régulièrement organisés.
Sur Lyon, on a lancé les réunions entre Fedoristas, on retrouve aujourd'hui la même chose sur Paris et ailleurs. D'ailleurs nos collègues parisiens ont enrichi le concept en l'associant à un blog dédié, idée que l'on a récupéré par la suite.
Au niveau européen, les ambassadeurs francophones ont été représentés lors des diverses réunions au sujet de la création Fedora Europe/EMEA.
Le travail de la communauté francophone est reconnu à sa juste valeur dans la communauté Fedora, nous avons créé la première structure locale regroupant utilisateurs et contributeurs, nous avons un projet documentation cohérent, une boutique.
On essaie également d'encourager l'écriture d'articles (si vous cherchez des auteurs, des relecteurs, passez nous voir sur irc ou contactez-nous par mail)
La blague a donné l'opportunité à l'IEEE journal de faire un entretien avec Bjarne Stroustrup. Voici le lien du véritable entretien sur le site de B.S : http://www.research.att.com/~bs/ieee_interview.html
NetworkManager et WICD n'ont pas les mêmes ambitions, le premier est un véritable framework réseau versatile et le second un frontend aux wireless tools.
Tu devrais essayer la branche 0.7 qui est nettement meilleure que la branche 0.6.x
Si tu veux mon opinion d'empaqueteur: WICD est typiquement le logiciel ubunto-centrique, bref un cauchemar à empaqueter.
A l'origine, le projet ne fournissait pas de tarballs des sources et la gestion des branches se faisait au petit bonheur la chance.
Suite à ma demande, le projet fournit désormais un tarball des sources mais en vrac (avec pas mal de code non pas spécifique à Ubuntu mais à plusieurs versions !), pas un makefile, pas un script d'installation: nada. En gros, si tu n'utilises pas Ubuntu, tu peux aller te torcher ou installer manuellement les fichiers.
Bref, WICD c'est clairement du bricolage.
D'ailleurs WICD n'est pas très populaire en dehors d'Ubuntu.
Fedora a son propre projet marketing, RedHat nous alloue un budget conséquent (géré par Paul Frields FedoraProject Leader), des Community Manager chargé en autre de la communication (comme Rahul Sundaram et bien d'autres), un Community Manager dédié au marketing (Jack Aboutboul). Sans compter la présence d'un artiste professionnel pour superviser l'équipe artistique.
L'ancien FedoraProject Leader Max Spevack devrait s'occuper plus spécifiquement de la zone EMEA (construction d'un Fedora Europe sur l'impulsion des ambassadeurs locaux, d'une boutique européenne) et coordonner les principaux événements.
RedHat a cédé la direction effective du projet à la communauté, ils nous donnent déjà du pognon, des ressources pour assurer la promo, on va pas leur demander d'en rajouter.
ça nous donne un peu plus d'indépendance, comme pouvoir partager des espaces avec des copains comme CentOS, de ne pas se déguiser en vendeur costume 2 pièces cravate incluse pour RedHat.
De notre côté, on fait la promo de FedoraProject et uniquement de FedoraProject.
[^] # Re: Autres logiciels libres....
Posté par GeneralZod . En réponse au journal Transifex: libérer votre plateforme l10n. Évalué à 4.
Comme tu l'as souligné, les outils pour traiter les fichiers de traduction sont relativement éprouvés, gettext fournit un mode emacs, mais il y a des outils plus user-friendly comme kBabel (qui est assez populaire parmi les traducteurs de FedoraProject), gtranslator etc ...
Le gros problème des traducteurs se résume principalement à un mot: "collaboration".
Collaboration entre traducteurs, collaboration traducteur/développeur, collaboration distribution/upstream etc ....
FedoraProject utilisait Damned Lies pour gérer les traductions, le problème est DL dépends des outils GNOME (intltool et gnome-doc-utils), pas très pratique pour collaborer avec d'autres projets.
C'est là que Transifex intervient, il réalise une abstraction du VCS utilisé, il peut utiliser le système d'authentification du projet, les fichiers sont directement envoyé aux projets upstream contrairement à Rosetta donc pas de doublons.
Dans Rosetta, soit le projet est hébergé par Launchpad (sapusaipalibre), soit on importe le projet que l'on veut traduire, et dans ce dernier cas, on duplique l'effort de traduction, il faut fusionner à la main. Bref c'est un bordel sans nom, et la collaboration entre les traducteurs est nulle.
Transifex offre un seul et unique point d'entrée pour le traducteur, il s'inscrit et permettant de créer une communauté de traducteurs à la disposition des projets inscrits. Pour beaucoup de petits projets qui ont du mal à trouver des traducteurs, c'est une aubaine.
# Why ?
Posté par GeneralZod . En réponse à la dépêche Gestion de l'énergie : se dépêcher de ne rien faire. Évalué à 7.
D'ailleurs, je recommande la lecture des billets précédents qui sont tout aussi intéressants autour ce sujet (ACPI, interaction pilotes graphiques/gestion d'énergie)
http://www.flickr.com/photos/kernelslacker/1397519526/
[^] # Re: Différence avec Rosetta
Posté par GeneralZod . En réponse au journal Transifex: libérer votre plateforme l10n. Évalué à 5.
[^] # Re: Les facilités ?
Posté par GeneralZod . En réponse au journal Transifex: libérer votre plateforme l10n. Évalué à 2.
[^] # Re: Enfin
Posté par GeneralZod . En réponse au journal QGtkStyle: un style Qt qui utilise les widgets GTK+. Évalué à 3.
[^] # Re: La réponse d'Aaron Seigo
Posté par GeneralZod . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
Même dans GNOME, certains modules ne sont pas garantis comme étant stable au niveau de l'API ou de l'ABI, par exemple GStreamer.
Dans la mesure du possible, on évite de tout casser mais parfois tu n'as pas le choix.
[^] # Re: La réponse d'Aaron Seigo
Posté par GeneralZod . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 6.
Tu te trompes à ce sujet. Si tu décides que les distributions majeures utiliseront le même noyau, le même X, le même GCC, les constructeurs se borneront à supporter ces versions et point barre.
Si tu cales ton cycle de développement sur celui des pilotes/logiciels propriétaire, tu es foutu. Si un constructeur refuse de supporter tel ou tel version du noyau ou de Xserver, tu fais quoi? selon Mark S., soit je fige mon interface pour lui faire plaisir, soit je fous des gros hacks pourris pour contourner ça.
C'est ce que faisait XGL ou Beryl avec les pilotes propriétaires, au fur et à mesure des hacks, la situation est devenu inmaintenable.
Au final, c'est AIGLX qui a gagné parce qu'ils ont préféré faire les choses proprement et qu'ils ont obligé les constructeurs à adapter leurs pilotes. Idem pour Beryl qui a disparu au profit de Compiz.
La synchronisation n'est pas une mauvaise chose, mais il faut des objectifs communs, c'est ce que fait Eclipse, Freedesktop.org.
Mais ça ne peut pas marcher entre des distributions ayant des objectifs différents, avec un calendrier rigide sur 2 ans alors que la plupart des logiciels libres n'ont pas une vision claire de ce que sera leur avenir au-delà de 6mois/1 an.
ça ne peut par marcher, si on joue dans un rapport de force entre distributions/upstream.
Si il doit avoir synchronisation, elle doit se faire en upstream et pas ailleurs.
> la facilité offerte aux développeurs de solutions propriétaires serait également offerte aux développeurs du libre.
Justement, le logiciel libre n'a pas besoin de cette facilité. Quand on casse une interface dans le noyau ou dans X, les pilotes sont quasi automatiquement corrigés que ce soit par le mainteneur du pilote, du changement d'API, ou un tiers.
G. K-H explique très bien pourquoi une API interne stable dans Linux n'a pas de sens et n'est pas souhaitable.
C'est même un argument majeur pour libérer les pilotes, les boites propriétaires n'ont guère le choix, soit elles fournissent un effort supplémentaire pour suivre les développements, soit elles libérent les informations. Sur le long terme, seule la seconde solution est viable.
Ce que tu appelles difficulté est en fait une force du libre, à tout moment, si un composant n'est pas satisfaisant, je peux le remplacer sans avoir à me retenir.
Si tu prends Gnome-vfs, c'était une merde en pourriture, plus personne n'osait y toucher. En moins de 6 mois, on a pu écrire un remplaçant gvfs -avec une meilleure architecture- et modifier tout gnome afin d'utiliser celui-ci.
Aurait-il été de possible de faire de même si on devait se soucier de la compatibilité ? si on ne pouvait pas modifier le code librement ?
> c'est une perte de ces différences qui seraient préjudiciables aux projets qui seraient délaissés par toutes les distributions participant.
Si on poussait la logique jusqu'au bout, effectivement, on aurait une espèce de méta-distribution avec des différences mineures.
C'était envisageable dans le cadre des distributions dérivées de Debian mais ça ne l'est pas au niveau des distributions GNU/Linux.
[^] # Re: La réponse d'Aaron Seigo
Posté par GeneralZod . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 5.
Mais ce qui arriverait, si les distributions majeures acceptaient cette proposition de figer les composants majeurs. Aujourd'hui, le nombre de pilotes propriétaire dans Linux est relativement restreint mais si on leur facilite la tâche, ils se multiplieront et on finira par ne plus pouvoir s'en passer. Et quand on sera tributaire des pilotes propriétaires, on sera poings et pieds liés.
On ne pourra plus corriger le noyau ou X ou du moins proprement si on a le malheur de casser un pilote.
Hein, il parle dans un second temps d'étendre ce concept au bureau, vous imaginez le jour ou il faudra faire de gros hacks pour ne pas casser MS Office Linux Edition parce que MS ne prévoit pas de mises à jour avant 3 ans.
# La réponse d'Aaron Seigo
Posté par GeneralZod . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 6.
Ce billet est une réponse au billet d'Aaron Seigo (LE guru KDE) qui explique pourquoi l'idée de Mark S. est stupide
-----------------------------------------------------------------------------------
On pouvait considérer le premier billet comme une intervention maladroite voire naïve mais là, il s'enfonce, c'est même dangereux ce qu'il propose.
The aim would be to encourage as much collaboration and discussion around component versions in the distributions, so that they can effectively exchange information and patches and bug reports.
Si toutes les distributions collaboraient un peu plus en upstream, ce serait inutile.
Si on doit partager des informations, des patchs et des rapports de bogues, ça doit être fait au niveau de l'upstream et uniquement à ce niveau-là.
ça n'empêche pas aux distributions d'avoir un espace d'échange pour partager leurs expérience au niveau du packaging, de l'intégration mais ça ne doit pas faire doublon avec l'upstream.
Some folks have said that my interest in this is “for Canonical”, or “just for Ubuntu”. And that’s really not true.
On y croit vachement.
I think it’s a much more productive approach for the whole free software ecosystem, and will help us compete with the proprietary world.
FOUTAISES ! Le but du logiciel libre est de fournir une alternative au logiciel propriétaire pas de l'affronter. ça c'est l'objectif des boites commerciales autour du libre que ce soit Canonical, RedHat, Novell etc... Les boites et le logiciel ont des intérêts communs mais nos objectifs ne sont pas les mêmes.
we’re more likely to have the same versions of key components at any given time.
C'est exactement ce qui lui a été proposé dans Debian Common Core et c'est exactement ce qu'il a refusé.
these are items which likely need the most stabilisation and testing before they ship to the innocent
C'est un travail de tout les jours, ce n'est pas en focalisant sur une version précise qu'on améliorera la situation. Pour cela, il n'y a pas de secret, il faut travailler en UPSTREAM.
I’ve talked with kernel developers who have said they would LOVE to know which kernel version is going to turn into RHEL or an Ubuntu LTS release, and ideally, they would LOVE it if those were the same versions, because it would enable them to plan their own work accordingly. So let’s do it!
On voudrait des noms, parce qu'à part les éventuels développeurs noyaux employés par Canonical j'y crois pas un instant.
Si il est capable de citer les personnes qui ne sont pas d'accord avec lui, il peut très bien faire l'inverse.
we would be able to improve greatly ALL of their support for today’s hardware
C'est le truc qui m'a le plus énervé. En gros, son but est de stabiliser les gros composants des principales distributions pour faciliter le support des pilotes propriétaires.
Alors que la communauté du logiciel libre se bat pour la libération des specs et des pilotes, Mark Shuttleworth lui enfonce un poignard dans le dos.
Et après, il ose dire qu'il soutient le logiciel libre ? Autant ce discours est compréhensible dans la bouche d'un chef d'entreprise, autant c'est inadmissible de la part d'un libriste.
Favoriser les pilotes propriétaires ne feront pas et ne feront jamais avancer le logiciel libre, ça peut favoriser les affaires d'une boite commerciale à un moment donné mais basta.
Mark S. nous propose un modèle propriétaire, seuls les composants sélectionné par les "boites" auront un support matériel correct, les autres devront marcher au pas.
Les constructeurs ne supporteront que les composants sélectionnés (les autres iront se faire foutre), les constructeurs n'auront pas envie de changer de politique vis à vis des pilotes libres (après tout, ça marcherait bien comme ça) ça reviendrait à faire un doigt aux autres plateformes libres (*BSD & cie), ils n'ont qu'à utiliser Linousque LTS (la fusion entre Ubuntu LTS, RHEL, etc ...)
Le pire c'est qu'il prévoit d'étendre ça à d'autres composants, c'est à dire à plus moins long terme, la sclérose de GNU/Linux, Il ne faudra plus casser les pilotes et logiciels propriétaires, bref, on finira comme Windows, une plateforme fade et sans innovation, trainant de gros boulets.
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par GeneralZod . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 2.
C'est ce qui est arrivé avec le problème concernant le laptop-mode-tools dans Ubuntu, ils ont récupéré le paquet Debian sans vraiment regarder ce qu'il y avait dedans.
Mais comme tu dis, le problème est connu depuis longtemps mais aucune action concrète n'a été prise pour améliorer ce point.
[^] # Re: Distro
Posté par GeneralZod . En réponse au journal 140 milliard de $ par jour traité par GNU/Linux. Évalué à 2.
[^] # Re: Distro
Posté par GeneralZod . En réponse au journal 140 milliard de $ par jour traité par GNU/Linux. Évalué à 2.
# Le problème OpenSSL dans Debian et ses dérivés vu par Roland Mas
Posté par GeneralZod . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 2.
Bonne lecture !
http://roland.entierement.nu/blog/2008/05/15/branle-bas-sshs(...)
[^] # Re: Distro
Posté par GeneralZod . En réponse au journal 140 milliard de $ par jour traité par GNU/Linux. Évalué à 4.
http://h20293.www2.hp.com/portal/swdepot/displayProductsList(...)
Je veux bien un bisou de ta copine.
[^] # Re: firefow 3.0 beta 5
Posté par GeneralZod . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 3.
Pose la question à IBM.
http://www.ibm.com/products/fr/fr/
[^] # Re: ppc et ppc64 !
Posté par GeneralZod . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 3.
Cette fois-ci, on s'est pris à la bourre pour écrire les annonces (il y a 2 versions), d'ailleurs je t'invite à la rédaction des annonces pour Fedora 10 si tu en as le temps (ça se passe sur la mailing-list fedora-fr), on aurait besoins de bons yeux comme les tiens ne serait-ce que pour relire le contenu. :)
> Côté SeLinux, notons que les utilisateurs commencent à être "confinés".
Xguest aurait effectivement pu avoir sa place dans l'annonce. ça fait partie des aspects méconnus de Fedora qui gagnerait à être mis en valeur.
[^] # Re: firefow 3.0 beta 5
Posté par GeneralZod . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 2.
NéanmoinsMark Shuttleworth et Canonical n'hésitent pas à comparer Ubuntu LTS à RHEL ou Novell SuSE. Du moins, il y a une volonté de les concurrencer, comme l'indique le revirement stratégique de Canonical sur les serveurs, leur grille tarifaire (ils sont plus cher que RedHat à service plus ou moins égal). Le récent billet de Mark S. est suffisamment explicite à ce sujet.
# Think tank pro-linux/BSD?
Posté par GeneralZod . En réponse au journal Espace de réflexion progressiste. Évalué à 4.
On n'a pas besoin d'un deuxième championnat d'ultimate fighting.
http://www.ufc.com/
[^] # Re: firefow 3.0 beta 5
Posté par GeneralZod . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 4.
J'ai juste dit que son installation ailleurs que sur une Ubuntu était pénible:
* pour l'utilisateur qui l'installe à partir des sources. T'as regardé le contenu de la tarball des sources?
* pour l'empaqueteur qui doit se faire chier à scripter l'installation et corriger les ubuntu-ismes dans le code.
Regarde la page concernant l'installation sur Fedora7
http://wicd.net/wiki/doku.php?id=fedora
Et encore, à l'époque où j'avais empaqueté le bousin, c'était pire encore. Vu le peu d'intérêt de l'upstream pour rendre leur machin portable sur d'autres distributions, je ne l'ai pas proposé dans FPC.
[^] # Re: firefow 3.0 beta 5
Posté par GeneralZod . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 2.
Firefox 2 est en fin de vie, Ubuntu LTS est supporté pendant 3 ans pour la partie desktop. Cela signifie que Canonical aurait du maintenir seule Firefox 2 pendant près de 3 ans ou bien laisser s'accumuler les failles de sécurités, ce n'est pas clairement pas tenable pour eux.
Quant à RH, ils comptent inclure Firefox 3 dans RHEL 5.2 (actuellement en béta) et ce malgré qu'ils disposent d'une forte expertise dans le domaine (RH emploie pas mal de développeurs Mozilla et pas mal de développeurs Mozilla contribuent à Fedora). Mais avant de lâcher RHEL 5.2, celle-ci sera blindé de tests
Ce n'est pas tant le choix de FF3 qui est à remettre en question dans Ubuntu que la rigidité du calendrier (il aurait fallu décaler la sortie) et le problème récurrent dans la chaine de test.
Pour le premier, Mark Shuttleworth s'est encore plus enfoncé avec son dernier billet, quant au second, il faut embaucher une vraie équipe de testeurs y a pas 36000 solutions.
Il faudra probablement attendre Ubuntu 8.04.1 pour avoir une version digne du nom LTS.
[^] # Re: firefow 3.0 beta 5
Posté par GeneralZod . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 2.
Sur Lyon, on a lancé les réunions entre Fedoristas, on retrouve aujourd'hui la même chose sur Paris et ailleurs. D'ailleurs nos collègues parisiens ont enrichi le concept en l'associant à un blog dédié, idée que l'on a récupéré par la suite.
Au niveau européen, les ambassadeurs francophones ont été représentés lors des diverses réunions au sujet de la création Fedora Europe/EMEA.
Le travail de la communauté francophone est reconnu à sa juste valeur dans la communauté Fedora, nous avons créé la première structure locale regroupant utilisateurs et contributeurs, nous avons un projet documentation cohérent, une boutique.
On essaie également d'encourager l'écriture d'articles (si vous cherchez des auteurs, des relecteurs, passez nous voir sur irc ou contactez-nous par mail)
[^] # Re: Interview
Posté par GeneralZod . En réponse au journal Entretien avec Bjarne Stroustrup sur l'évolution des langages.. Évalué à 3.
http://en.wikipedia.org/wiki/UNIX-HATERS_Handbook
La blague a donné l'opportunité à l'IEEE journal de faire un entretien avec Bjarne Stroustrup. Voici le lien du véritable entretien sur le site de B.S :
http://www.research.att.com/~bs/ieee_interview.html
[^] # Re: firefow 3.0 beta 5
Posté par GeneralZod . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 7.
Tu devrais essayer la branche 0.7 qui est nettement meilleure que la branche 0.6.x
Si tu veux mon opinion d'empaqueteur: WICD est typiquement le logiciel ubunto-centrique, bref un cauchemar à empaqueter.
A l'origine, le projet ne fournissait pas de tarballs des sources et la gestion des branches se faisait au petit bonheur la chance.
Suite à ma demande, le projet fournit désormais un tarball des sources mais en vrac (avec pas mal de code non pas spécifique à Ubuntu mais à plusieurs versions !), pas un makefile, pas un script d'installation: nada. En gros, si tu n'utilises pas Ubuntu, tu peux aller te torcher ou installer manuellement les fichiers.
Bref, WICD c'est clairement du bricolage.
D'ailleurs WICD n'est pas très populaire en dehors d'Ubuntu.
[^] # Re: firefow 3.0 beta 5
Posté par GeneralZod . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 4.
Fedora a son propre projet marketing, RedHat nous alloue un budget conséquent (géré par Paul Frields FedoraProject Leader), des Community Manager chargé en autre de la communication (comme Rahul Sundaram et bien d'autres), un Community Manager dédié au marketing (Jack Aboutboul). Sans compter la présence d'un artiste professionnel pour superviser l'équipe artistique.
L'ancien FedoraProject Leader Max Spevack devrait s'occuper plus spécifiquement de la zone EMEA (construction d'un Fedora Europe sur l'impulsion des ambassadeurs locaux, d'une boutique européenne) et coordonner les principaux événements.
RedHat a cédé la direction effective du projet à la communauté, ils nous donnent déjà du pognon, des ressources pour assurer la promo, on va pas leur demander d'en rajouter.
ça nous donne un peu plus d'indépendance, comme pouvoir partager des espaces avec des copains comme CentOS, de ne pas se déguiser en vendeur costume 2 pièces cravate incluse pour RedHat.
De notre côté, on fait la promo de FedoraProject et uniquement de FedoraProject.
[^] # Re: Modesetting *dans le noyau*
Posté par GeneralZod . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 2.