Plus que la présence de deux francais, il me semble important de noter que Raphael Hertzog pousse dans la direction d'un "board" pour diriger le projet Debian.
Ca serait assez révolutionnaire pour Debian, qui a toujours été dirigé par un leader unique.
Effectivement avec Leslie Lamport, c'est pas pour innover sur (Open) Office ...
Oui, exactement. Je trouve dommage que personne ne se rende compte qu'il s'agit d'une association entre Microsoft RESEARCH et l'INRIA, pas entre Microsoft et l'INRIA. Microsoft Research a en gros le même statut que FT R&D: l'objectif n'est pas de produire des logiciels microsoft, mais de produire des résultats de recherche, le plus souvent sous la forme de publications (et MSR joue très bien le jeu de ce côté là, je ne pense pas que ses employés sont empêchés de publier vu le volume de publis venant de MSR).
Il est très rare que ces résultats soient sous la forme de logiciels utilisables par tout un chacun. Le plus souvent, dans le meilleur des cas, c'est des prototypes, pas vraiment d'une qualité merveilleuse (normal, c'est pas ce qu'on leur demande). A part scilab et mldonkey, il n'y a pas beaucoup de logiciels produits par l'INRIA et connus en dehors du monde académique. (encore que pour mldonkey, je ne crois pas que ce soit clairement affiché)
En fait, la création de ce labo commun est plutot positive : ca montre que l'INRIA a une place suffisamment importante dans la recherche en informatique pour s'attirer des financements de boites américaines.
Je m'étais amusé il y a quelques semaines à comparer la "qualité" d'Ubuntu Dapper et de Debian Etch à l'aide d'une métrique qui vaut ce qu'elle vaut. Le résultat était que Etch était déjà de meilleure qualité que Dapper. Cf http://www.lucas-nussbaum.net/blog/?p=224
D'autre part, il faut noter que cette notion de nombre de bugs critiques est assez artificielle. Il y a des bugs critiques très simples à corriger (la plupart des bugs que j'ai signalé en cherchant des paquets qui ne rebuildaient pas le sont), et d'autres très très difficiles à corriger. De plus, il y a des bugs qui affectent des paquets sans lesquels on ne peut raisonnablement pas releaser, et d'autres qui qui affectent des paquets avec un score popcon très faible. Pour faire baisser le nombre de bugs RC, il suffirait alors de supprimer ces paquets là.
> Mais, heu, c'est pas une machine de bureau un cluster, ça ne se redémarre pas
> tous les jours pour s'amuser avec l'appli X qui nécessite tel ou tel environnement !!
> C'est quoi ce délire.
Certains clusters permettent justement de redéployer l'environnement utilisé, pour permettre aux utilisateurs d'avoir le root sur les noeuds, et d'installer leur propre environnement de travail. Il est donc possible de changer de distribution linux, de passer sous FreeBSD, etc. Le temps nécessaire pour déployer son propre environnement est d'environ 5 minutes (et ne varie quasiment pas en fonction du nombre de noeuds à redéployer). Le soft utilisé pour faire ça sur Grid'5000 est kadeploy, il existe des alternatives comme Freesbie utilisées ailleurs. Il me semble qu'il y a un support Windows dans kadeploy, mais à ma connaissance, personne ne l'a utilisé.
> MPI est plus rapide sur Linux que sur *BSD ?
> C'est une vraie question : j'aurais parié l'inverse moi.
qu'est-ce qui te fait penser l'inverse ?
En fait, je ne sais pas. Mais j'imagine que les libs MPI sont principalement développées sous Linux, et vu que la performance est cruciale, le support de Linux doit probablement bénéficier de pas mal de petits hacks.
Mais on peut y déployer du FreeBSD si on veut (kadeploy supporte les systèmes autres que Linux via des images ".dd.gz", ce qui est forcément nettement moins rapide que les images .tgz utilisées pour Linux).
Je pense que les raisons de la domination sans partage de Linux sont plutôt à chercher du coté des drivers proprio de certains chips réseaux, du support SMP (FreeBSD a laissé tomber le Big Kernel Lock plus tardivement que Linux), et peut-être des perfs des libs MPI.
Ouah, je suis cité sur LinuxFR sans qu'on me le dise ;)
Je recommande la lecture du billet sur mon blog, pas parce que c'est mon blog, mais juste parce que ca montre un bon exemple de la nullité absolue de Tele2.
Liens vers le soft et ce journal ajoutés sur mon blog.
> 14 20:53:14 -*- aba is definitly not the right person to fix the bugs
> chacun en tirera les enseignements qu'il souhaite.
Je trouve ça normal. Andreas Barth (aba) est l'un des Release *Manager*. Son rôle n'est pas de passer son temps à corriger tous les bugs RC, mais à coordonner leur correction par l'ensemble des autres mainteneurs, et bien d'autres choses encore. C'est la signification du "Manager" dans le titre de son rôle. :-)
S'acharner à vouloir montrer que payer les RM est une mauvaise idée car ils font mal leur boulot me semble une stratégie un peu facile.
Pour moi, Dunc Tank soulève deux questions distinctes:
(1) L'idée de payer certains développeurs Debian est-elle une bonne idée ?
(2) Est-ce qu'appliquer cette idée au paiement des RM est une bonne idée ?
Avec votre stratégie de défense, vous semblez vous attaquer principalement à (2), alors que je trouve (1) vachement plus intéressant/facile à attaquer (cf les problèmes sociologiques posés par le paiement de certains volontaires dont j'avais parlé dans [1]).
pourquoi ne pas parler de ça , qui sont des informations importantes et dire que tout va bien aller ?
Je pense (c'est mon humble avis) que ces démissions et ces abandons de paquets sont et resteront marginaux. Leur objectif, il me semble, est principalement de pouvoir dire que tout ne va pas bien. Je m'attends à ce que les mainteneurs qui ont abandonné leurs paquets reprennent au moins certains d'entre eux dans peu de temps.
De plus, je n'étais pas au courant au moment où j'ai écrit la news (ce matin), je n'avais pas encore debian-devel@. Même si c'était à refaire, je ne sais pas si j'aurais rallongé la news, qui est déjà assez longue comme ça.
Concernant les insultes:
Même s'il s'avérait vrai que je n'ai été insulté que par une seule personne (ce que je n'ai pas percu comme tel), est-ce qu'un différent sur un article de mon blog[1], et une news qui n'a pas été jugée partiale par les modérateurs les justifieraient ? Après tout, on fait tous partie de la même communauté, et il me semble qu'on poursuit tous plus ou moins le même idéal. S'abaisser jusqu'à des insultes me semble vraiment inutile et choquant, alors qu'on pourrait profiter de flame-wars pour se taper sur la gueule (</humour>).
[1] http://www.lucas-nussbaum.net/blog/?p=211 , considéré comme du FUD par la personne en question, alors que personne d'autre ne s'est élevé contre pour l'instant.
En fait, je voulais dire que parmi les 48 personnes qui ont voté pour le "recall" du projet leader, il y a plusieurs francophones qui vont probablement venir ici dire que ma news est complètement pourrie, puisqu'ils viennent de me traiter de "connard", de "pauvre con" et de "tete de con" sur #debian-devel-fr. :-)
Heureusement, ils ne représentent ni la majorité des développeurs Debian, ni la majorité des développeurs Debian francophones.
D'autre part, je précise juste que les liens sur le conflit Mozilla/Debian n'étaient pas dans la version de la news que j'ai soumise. Je trouve un peu dommage que les modérateurs aient choisi de la "récupérer" pour parler de ça, alors que les deux articles liés ne sont pas d'une grande qualité et qu'une news spécifique aurait probablement eu sa place d'ici quelques jours, quand on en saura plus.
Mon avis n'est pas vraiment sceptique. J'ai juste mentionné le fait que dans de nombreux cas, il a été démontré que le fait de payer des volontaires faisait en fait baisser la participation totale au projet.
Appliqué à Dunc Tank, ça veut juste dire que cette "expérience" peut se réveler dangereuse, et qu'il faut faire attention. Mais j'aurais plutot tendance à faire confiance à Raphael et aux autres pour ne pas faire de bêtises :-)
Hé, ton idée est vraiment intéressante ! Ca serait vraiment quelque chose de cool à implémenter au dessus de Jabber. Ca simplifierait en plus la recherche des interlocuteurs, puisqu'il suffirait de prendre les gens "Free for chat" par exemple.
nul. saloperie. kernel foireux. paquet à la con. copie complète à revoir.
Dis moi, ça te dérangerai de respecter un peu le boulot des gens qui bossent sur cette distribution, et qui n'apprécient pas forcément de se faire traiter comme de la merde ?
Tu développes quoi toi, qu'on puisse critiquer tes softs d'une manière aussi aiguisée ?
Et pour grub qui ignore tes modifs, si tu avais lu un peu le début de /boot/grub/menu.lst fichier, tu aurais compris pourquoi.
Pour les différents points de ton message:
* mauvais packageur, râler sur ses packageurs. Notre packageur Debian fait du très bon boulot sur Sylpheed-Claws par exemple. Le seul patch qu'il ajoute, c'est parce qu'on l'a refusé.
Comme je l'ai dit plus haut, ce cas là ne concerne qu'un très faible pourcentage de packageurs Debian.
* Hop un ptit troll Ubuntu pour la route !
Boh, non, surtout que je fais partie de l'équipe d'Ubuntu à laquelle on reproche de ne pas toujours faire remonter les bugs/patchs.
> j'ai l'impression qu'on dérive souvent vers une amélioration de son confort personnel/de ses proches...
Il est vrai que les rapports de bugs en provenance de ma copine se retrouvent souvent avec une priorité supérieure aux autres. J'ai honte de moi !
> La politique debian vis à vis de l'upstream me semble très claire :
Effectivement, c'est la "policy" de Debian. Mais comme le dit Misc, il faut faire la différence entre "policy" et pratique.
Concernant Debian, c'est un exemple que je connais bien, et c'est vrai que le nombre de paquets avec des modifications utiles non remontées esttrès faible (mais pas nul non plus).
Enfin le but de mon journal n'était pas de râler contre Debian de toute facon, ca n'était qu'un exemple parmi d'autres.
PS: je ne comprends pas ce que cliquer simplement sur "Connecter" aurait dû faire... sur un téléphone normal cela prend la ligne et c'est tout. On ne peut pas deviner qui l'utilisateur veut joindre !
En fait, mon problème est que, n'ayant jamais utilisé GnomeMeeting (ou il y a très longtemps), il est difficile de répondre au besoin "je veux utiliser GnomeMeeting vite fait pour discuter avec ma copine". Apparemment, la bonne manière de faire est de s'inscrire dans l'annuaire, puis de chercher sa copine dans l'annuaire. Mais ce n'est dit nulle part. Pourquoi ne pas le mentionner dans le dernier écran du "configuration druid" ?
# vers un board pour diriger le projet Debian ?
Posté par Lucas . En réponse à la dépêche Élections du responsable du projet Debian 2007. Évalué à 6.
Ca serait assez révolutionnaire pour Debian, qui a toujours été dirigé par un leader unique.
[^] # Re: Pb site
Posté par Lucas . En réponse au journal Script pour récupérer les adresses des vidéos de France 5. Évalué à 1.
[^] # Re: Rassurant
Posté par Lucas . En réponse à la dépêche Inauguration du labo commun INRIA-Microsoft. Évalué à 10.
Oui, exactement. Je trouve dommage que personne ne se rende compte qu'il s'agit d'une association entre Microsoft RESEARCH et l'INRIA, pas entre Microsoft et l'INRIA. Microsoft Research a en gros le même statut que FT R&D: l'objectif n'est pas de produire des logiciels microsoft, mais de produire des résultats de recherche, le plus souvent sous la forme de publications (et MSR joue très bien le jeu de ce côté là, je ne pense pas que ses employés sont empêchés de publier vu le volume de publis venant de MSR).
Il est très rare que ces résultats soient sous la forme de logiciels utilisables par tout un chacun. Le plus souvent, dans le meilleur des cas, c'est des prototypes, pas vraiment d'une qualité merveilleuse (normal, c'est pas ce qu'on leur demande). A part scilab et mldonkey, il n'y a pas beaucoup de logiciels produits par l'INRIA et connus en dehors du monde académique. (encore que pour mldonkey, je ne crois pas que ce soit clairement affiché)
En fait, la création de ce labo commun est plutot positive : ca montre que l'INRIA a une place suffisamment importante dans la recherche en informatique pour s'attirer des financements de boites américaines.
[^] # Re: C'est qui Etch
Posté par Lucas . En réponse au journal Etch sous la barre des 100. Évalué à 3.
Je m'étais amusé il y a quelques semaines à comparer la "qualité" d'Ubuntu Dapper et de Debian Etch à l'aide d'une métrique qui vaut ce qu'elle vaut. Le résultat était que Etch était déjà de meilleure qualité que Dapper. Cf http://www.lucas-nussbaum.net/blog/?p=224
D'autre part, il faut noter que cette notion de nombre de bugs critiques est assez artificielle. Il y a des bugs critiques très simples à corriger (la plupart des bugs que j'ai signalé en cherchant des paquets qui ne rebuildaient pas le sont), et d'autres très très difficiles à corriger. De plus, il y a des bugs qui affectent des paquets sans lesquels on ne peut raisonnablement pas releaser, et d'autres qui qui affectent des paquets avec un score popcon très faible. Pour faire baisser le nombre de bugs RC, il suffirait alors de supprimer ces paquets là.
# codé...
Posté par Lucas . En réponse au journal vidéos de france 5: flux RSS ?. Évalué à 1.
[^] # Re: Windows dans le top 500 !
Posté par Lucas . En réponse à la dépêche Top500 des supercalculateurs. Évalué à 4.
> tous les jours pour s'amuser avec l'appli X qui nécessite tel ou tel environnement !!
> C'est quoi ce délire.
Certains clusters permettent justement de redéployer l'environnement utilisé, pour permettre aux utilisateurs d'avoir le root sur les noeuds, et d'installer leur propre environnement de travail. Il est donc possible de changer de distribution linux, de passer sous FreeBSD, etc. Le temps nécessaire pour déployer son propre environnement est d'environ 5 minutes (et ne varie quasiment pas en fonction du nombre de noeuds à redéployer). Le soft utilisé pour faire ça sur Grid'5000 est kadeploy, il existe des alternatives comme Freesbie utilisées ailleurs. Il me semble qu'il y a un support Windows dans kadeploy, mais à ma connaissance, personne ne l'a utilisé.
[^] # Re: 3 BSD
Posté par Lucas . En réponse à la dépêche Top500 des supercalculateurs. Évalué à 1.
> C'est une vraie question : j'aurais parié l'inverse moi.
qu'est-ce qui te fait penser l'inverse ?
En fait, je ne sais pas. Mais j'imagine que les libs MPI sont principalement développées sous Linux, et vu que la performance est cruciale, le support de Linux doit probablement bénéficier de pas mal de petits hacks.
[^] # Re: 3 BSD
Posté par Lucas . En réponse à la dépêche Top500 des supercalculateurs. Évalué à 2.
Mais on peut y déployer du FreeBSD si on veut (kadeploy supporte les systèmes autres que Linux via des images ".dd.gz", ce qui est forcément nettement moins rapide que les images .tgz utilisées pour Linux).
Je pense que les raisons de la domination sans partage de Linux sont plutôt à chercher du coté des drivers proprio de certains chips réseaux, du support SMP (FreeBSD a laissé tomber le Big Kernel Lock plus tardivement que Linux), et peut-être des perfs des libs MPI.
# Ouah aussi
Posté par Lucas . En réponse au journal pppoesk : programme pour clore les 'sessions fantômes' PPPoE. Évalué à 3.
Je recommande la lecture du billet sur mon blog, pas parce que c'est mon blog, mais juste parce que ca montre un bon exemple de la nullité absolue de Tele2.
Liens vers le soft et ce journal ajoutés sur mon blog.
[^] # Re: Et la release dans tout ca ?
Posté par Lucas . En réponse à la dépêche Les développeurs Debian choisissent le pragmatisme et souhaitent bonne chance à Dunc Tank. Évalué à 2.
> chacun en tirera les enseignements qu'il souhaite.
Je trouve ça normal. Andreas Barth (aba) est l'un des Release *Manager*. Son rôle n'est pas de passer son temps à corriger tous les bugs RC, mais à coordonner leur correction par l'ensemble des autres mainteneurs, et bien d'autres choses encore. C'est la signification du "Manager" dans le titre de son rôle. :-)
S'acharner à vouloir montrer que payer les RM est une mauvaise idée car ils font mal leur boulot me semble une stratégie un peu facile.
Pour moi, Dunc Tank soulève deux questions distinctes:
(1) L'idée de payer certains développeurs Debian est-elle une bonne idée ?
(2) Est-ce qu'appliquer cette idée au paiement des RM est une bonne idée ?
Avec votre stratégie de défense, vous semblez vous attaquer principalement à (2), alors que je trouve (1) vachement plus intéressant/facile à attaquer (cf les problèmes sociologiques posés par le paiement de certains volontaires dont j'avais parlé dans [1]).
[1] http://www.lucas-nussbaum.net/blog/?p=208
[^] # Re: Hein?
Posté par Lucas . En réponse à la dépêche Les développeurs Debian choisissent le pragmatisme et souhaitent bonne chance à Dunc Tank. Évalué à 2.
Je pense (c'est mon humble avis) que ces démissions et ces abandons de paquets sont et resteront marginaux. Leur objectif, il me semble, est principalement de pouvoir dire que tout ne va pas bien. Je m'attends à ce que les mainteneurs qui ont abandonné leurs paquets reprennent au moins certains d'entre eux dans peu de temps.
De plus, je n'étais pas au courant au moment où j'ai écrit la news (ce matin), je n'avais pas encore debian-devel@. Même si c'était à refaire, je ne sais pas si j'aurais rallongé la news, qui est déjà assez longue comme ça.
Concernant les insultes:
Même s'il s'avérait vrai que je n'ai été insulté que par une seule personne (ce que je n'ai pas percu comme tel), est-ce qu'un différent sur un article de mon blog[1], et une news qui n'a pas été jugée partiale par les modérateurs les justifieraient ? Après tout, on fait tous partie de la même communauté, et il me semble qu'on poursuit tous plus ou moins le même idéal. S'abaisser jusqu'à des insultes me semble vraiment inutile et choquant, alors qu'on pourrait profiter de flame-wars pour se taper sur la gueule (</humour>).
[1] http://www.lucas-nussbaum.net/blog/?p=211 , considéré comme du FUD par la personne en question, alors que personne d'autre ne s'est élevé contre pour l'instant.
[^] # Re: Hein?
Posté par Lucas . En réponse à la dépêche Les développeurs Debian choisissent le pragmatisme et souhaitent bonne chance à Dunc Tank. Évalué à 10.
Heureusement, ils ne représentent ni la majorité des développeurs Debian, ni la majorité des développeurs Debian francophones.
Pour la liste des développeurs qui ont voté pour la destitution:
lynx -dump http://www.debian.org/vote/2006/vote_005_tally.txt |grep "^V: 1"
D'autre part, je précise juste que les liens sur le conflit Mozilla/Debian n'étaient pas dans la version de la news que j'ai soumise. Je trouve un peu dommage que les modérateurs aient choisi de la "récupérer" pour parler de ça, alors que les deux articles liés ne sont pas d'une grande qualité et qu'une news spécifique aurait probablement eu sa place d'ici quelques jours, quand on en saura plus.
[^] # Re: planet.debian.net
Posté par Lucas . En réponse à la dépêche Dunc-tank: comment aider à la publication de Etch en décembre. Évalué à 3.
Appliqué à Dunc Tank, ça veut juste dire que cette "expérience" peut se réveler dangereuse, et qu'il faut faire attention. Mais j'aurais plutot tendance à faire confiance à Raphael et aux autres pour ne pas faire de bêtises :-)
[^] # Ca existe déjà
Posté par Lucas . En réponse au journal Est-ce que vous trouvez que les applications GTK scintillent ?. Évalué à 5.
http://wiki.laptop.org/go/GTK_for_OLPC#GTK_theme.2Fengine_to(...)
Il y a aussi eu plusieurs posts là dessus sur Planet Gnome, dont http://www.manucornet.net/blog/dreamerant/?p=39
Et un thread sur la liste performance de gnome, qui commence ici :
http://mail.gnome.org/archives/performance-list/2006-August/(...)
# Une killer app pour Jabber ?
Posté par Lucas . En réponse au journal Le random chat, ou comment perdre son temps autrement. Évalué à 9.
# un journal "pourri" ... ;)
Posté par Lucas . En réponse au journal Kubuntu déception. Évalué à 9.
Dis moi, ça te dérangerai de respecter un peu le boulot des gens qui bossent sur cette distribution, et qui n'apprécient pas forcément de se faire traiter comme de la merde ?
Tu développes quoi toi, qu'on puisse critiquer tes softs d'une manière aussi aiguisée ?
Et pour grub qui ignore tes modifs, si tu avais lu un peu le début de /boot/grub/menu.lst fichier, tu aurais compris pourquoi.
# confirmé
Posté par Lucas . En réponse au journal possesseurs d'ATI demandés. Évalué à 3.
Tu as signalé un bug qqpart ?
[^] # Re: licence
Posté par Lucas . En réponse au journal De l'utilité des développements Libres. Évalué à 0.
[^] # Re: upstream versus packageur
Posté par Lucas . En réponse au journal De l'utilité des développements Libres. Évalué à 1.
* mauvais packageur, râler sur ses packageurs. Notre packageur Debian fait du très bon boulot sur Sylpheed-Claws par exemple. Le seul patch qu'il ajoute, c'est parce qu'on l'a refusé.
Comme je l'ai dit plus haut, ce cas là ne concerne qu'un très faible pourcentage de packageurs Debian.
* Hop un ptit troll Ubuntu pour la route !
Boh, non, surtout que je fais partie de l'équipe d'Ubuntu à laquelle on reproche de ne pas toujours faire remonter les bugs/patchs.
> j'ai l'impression qu'on dérive souvent vers une amélioration de son confort personnel/de ses proches...
Il est vrai que les rapports de bugs en provenance de ma copine se retrouvent souvent avec une priorité supérieure aux autres. J'ai honte de moi !
C'est pas vraiment ce à quoi je pensais ;)
[^] # Re: Qu'en pensez-vous ?
Posté par Lucas . En réponse au journal De l'utilité des développements Libres. Évalué à 1.
Pas du tout.
> La politique debian vis à vis de l'upstream me semble très claire :
Effectivement, c'est la "policy" de Debian. Mais comme le dit Misc, il faut faire la différence entre "policy" et pratique.
Concernant Debian, c'est un exemple que je connais bien, et c'est vrai que le nombre de paquets avec des modifications utiles non remontées esttrès faible (mais pas nul non plus).
Enfin le but de mon journal n'était pas de râler contre Debian de toute facon, ca n'était qu'un exemple parmi d'autres.
[^] # Re: iOpenOffice
Posté par Lucas . En réponse au journal dans l'intérêt de qui ?. Évalué à 1.
- Si je cherche Savane sur google, les chances que je me trompe en *rajoutant* un e au début sont plutot faibles
- Par contre, si je cherche eSavane, c'est assez facile d'ommettre le E
[^] # Re: audioconf à plusieurs ?
Posté par Lucas . En réponse au journal audio et vidéoconf sous Linux. Évalué à 1.
[^] # Re: eKiga 2.0
Posté par Lucas . En réponse au journal audio et vidéoconf sous Linux. Évalué à 2.
[^] # audioconf à plusieurs ?
Posté par Lucas . En réponse au journal audio et vidéoconf sous Linux. Évalué à 1.
Sinon, il y a des packages sur http://snapshots.gnomemeeting.net/ , c'est cool !
[^] # Re: eKiga 2.0
Posté par Lucas . En réponse au journal audio et vidéoconf sous Linux. Évalué à 1.
En fait, mon problème est que, n'ayant jamais utilisé GnomeMeeting (ou il y a très longtemps), il est difficile de répondre au besoin "je veux utiliser GnomeMeeting vite fait pour discuter avec ma copine". Apparemment, la bonne manière de faire est de s'inscrire dans l'annuaire, puis de chercher sa copine dans l'annuaire. Mais ce n'est dit nulle part. Pourquoi ne pas le mentionner dans le dernier écran du "configuration druid" ?