Quant à juger que MDI se disperse en « futilités contestables », renseigne-toi 5 minutes sur ce qu’est Mono avant. Il n’existe aucun, je dis bien aucun, framework de développement libre qui soit à moitié aussi complet que Mono. Tant en termes d’environnement de développement, de qualité et quantité de bibliothèques disponibles, de cohérence, que de nombre de langages supportés.
Il ne t’est jamais passé par la tête que si les gens l’utilisent, ce n’est pas par « besoin frénétique » mais tout simplement parce que c’est plus efficace de développer avec Mono ? Plus efficace même que de développer avec .Net, vu que Mono est plus performant et dispose de bibliothèques (comme Qt# et Gtk# en particulier).
Il est possible techniquement de faire des binaires compatibles avec les deux noyaux, c’est le projet GNU/Any, mais cela pose beaucoup de problèmes d’échelle et intéresse trop peu de monde pour l’instant.
Si tu penses que les autres distributions sont à l’abri de problèmes du genre de celui de Debian avec OpenSSL, tu te fourres le doigt dans l’œil jusqu’au coude. Chaque distribution applique des patches à des milliers de paquets, et il est évident que certains d’entre eux ajoutent des trous sans que personne ne le sache.
Que le mainteneur Debian d’OpenSSL ait complètement merdé, y compris dans la gestion de l’alerte, c’est évident. Mais pour avoir vu comment l’équipe de sécurité a rattrapé le coup, je pense que tu généralises beaucoup trop vite. Et des tanches bien pires que lui, il y en a dans les équipes de développement de toutes les distributions.
Bref, ce problème a touché Debian comme il aurait pu toucher n’importe qui. S’il avait touché Red hat, serais-tu aujourd’hui à cracher sur Red hat ? Est-ce que ça empêcherait leur équipe de sécurité de faire elle aussi un super boulot ? Contrairement aux fanboys de ton genre, la réaction des développeurs des autres distributions n’a pas été “Ololol Debian pwned” mais plutôt “Ouf, c’était pas nous”. Je t’assure que dans une telle situation, personne n’a intérêt à se la ramener (à part ceux qui ont r00té des machines grâce à la faille).
Enfin, si ça avait touché un logiciel propriétaire, crois-tu que tu serais seulement au courant de l’existence d’un tel problème ? Au passage, comme l’a fait très justement remarquer Schneier, ce genre de problèmes n’est pas nouveau, il est même souvent intentionnel, et il y a encore probablement beaucoup de logiciels affectés.
Pour ta gouverne, les release managers ne sont pas responsables d’écrire la documentation. Ils ont bien assez de boulot pour produire la release en elle-même.
Les paquets qu’il est possible d’inclure ou exclure dans testing en une commande sans rien casser, ce ne sont pas ceux qui empêchent de produire une release. Ceux-ci sont d’ailleurs déjà inclus uniquement quand ils n’ont pas de bug RC, et exclus quand ils en ont un qui n’est pas fixé pendant trop longtemps. Ta suggestion n’apporte rien car ce sont les autres paquets qui posent problème, ceux dont dépend une partie du système.
Encore heureux que ça n’arrive pas souvent. Quand on se rappelle qu’il a été recommandé de procéder à une mise à jour majeure pour corriger un trou de sécurité sur toutes les distributions tout en refusant de préciser la nature du trou, au lieu de se synchroniser sur vendor-sec pour fournir un correctif ciblé, effectivement on est content que ça n’arrive pas plus fréquemment, parce qu’à chaque fois c’est une catastrophe.
Écrire du code sécurisé et gérer le flux des problèmes de sécurité sont deux choses bien différentes. Les développeurs d’OpenSSH ne sont bons que pour l’une des deux problématiques - note, c’est toujours une de plus que pour ceux de Moizilla.
Elle est marrante votre discussion, mais vous devriez savoir qu’il est complètement inutile de comparer la gestion des patches de sécurité par Linux et Moizilla : ce sont, et de loin, les deux plus mauvais projets pour ce qui est de la gestion des correctifs de sécurité. Même OpenSSH fait mieux, c’est dire.
Regardez plutôt comment ça fonctionne pour des projets avec un bon processus de développement, comme Python, KDE ou GNOME. Là, pas besoin que les développeurs passent trois plombes à chercher où se trouve le correctif, et encore plus à tester toutes les mises à jour dont il dépend.
Pour ta gouverne, puisque ça continue dans les mythes à deux balles, dans Debian, si un paquet n’est pas supporté sur une architecture, il n’est pas supporté, point. Il n’a jamais été question de bloquer l’inclusion de quoi que ce soit pour des raisons de portabilité.
Les problèmes liés au support de nombreuses architectures provoquent ponctuellement des problèmes avec testing, qui n’ont pas d’impact sur le développement dans unstable. Donc dire que ça retarde les releases, c’est vrai dans une faible mesure, mais dire que ça retarde l’inclusion de fonctionnalités, c’est juste étaler ton ignorance.
Pour ta gouverne, non seulement supporter plein d’architectures ne représente quasiment rien en temps pour les mainteneurs (ça occupe surtout les porteurs), mais cela permet un travail de QA et de nettoyage du code qui n’aurait jamais lieu sinon.
J'ai regardé pour iceweasel (2.0.0.14), ça ne semble toujours pas le cas
C’est un problème dans la façon dont le paquet est distribué sur les miroirs, mais en interne les mainteneurs utilisent git et tous les patches sont correctement séparés dans la version distribuée sur git.debian.org.
Notons aussi comme il est étrange de voir Debian qui gueule après OpenSSL qui n'a pas audité ses patchs, alors que Debian ne voulait pas que Mozilla les audites ou n'a pas fait (encore ?) ce qu'a demandé Mozilla pour les auditer.
Personne n’a rien contre de l’audit de patches, au contraire. Par contre, une licence qui empêche de publier lesdits patches avant qu’ils aient été audités par une entité sur laquelle tu n’as aucun contrôle, ça c’est un problème.
C'est peut être assez complexe à embarquer, mais Gecko est tout de même conçu pour être embarqué. Y a une doc et tout. D'ailleurs, si il ne l'était pas, on se demande comment a fait epiphany pendant des années, et comment font les autres logiciels qui embarquent gecko.
Ils s’arrachent les cheveux. D’où l’abandon.
Gecko aussi est fait pour être réutilisé...
Non, trois fois non. Gecko est conçu pour être le moteur de Firefox. Le reste, c’est de la seconde zone.
Gecko aussi. Gecko repose aussi sur cairo, gtk et cie... D'ailleurs l'un des liens le précise. Bref, ce n'est pas un avantage à webkit.
Webkit dispose d’une API entièrement basée sur GObject, qui permet de l’intégrer directement au système de classes de GNOME. Alors que Gecko nécessite l’utilisation de couches d’interface tordues en C++ et d’une quantité de code de glu qui ne fait que croître avec le temps. Quant à parler de réutilisation de GTK+ Gecko, c’est à peu près autant le cas que pour Openoffice. Utilisé oui, mais très mal utilisé, d’où les lenteurs terribles du port X11 par rapport au port Windows, par exemple.
En quoi Gecko ne le serait pas ?
Parce que Gecko est une usine à gaz, et que contrairement aux idées reçues, les développeurs de GNOME cherchent à alléger leurs applications.
Non, c’est un constat objectif de comment les développeurs de Gecko axent leur développement. L’important pour eux, c’est de faire marcher Firefox, et le reste de toute façon est moins bien que l’extraaaaaordinaire Firefox, il est donc inutile de s’escrimer à le supporter.
Non. Le bon fonctionnement de gtkembedmoz est la dernière des priorités des développeurs. C’est déjà un miracle d’arriver à faire fonctionner quelque chose comme Epiphany dessus, et ça marche grâce à quantité de bidouilles immondes.
Le site indique également que pour distribuer CUPS (avec les noms et logos originaux) dans un produit dérivé (par exemple une version patchée) il faudra l'accord de la société Apple. C'est précisément ce type de clause chez Mozilla qui avait conduit à la création d'Iceweasel par les développeurs Debian.
Ce n'est pas tout-à-fait vrai, et surtout j'ai lu tout et n'importe quoi dans les commentaires.
Ce type de clause existe aussi pour la marque Apache. Pourtant, Debian distribue des paquets Apache modifiés qui portent le nom Apache (ce qu'au passage, Redhat a refusé). Il existe un accord qui permet à Debian de distribuer des paquets modifiés de manière raisonnable sans demander l'accord de la fondation Apache. Cet accord n'a pas été possible avec Mozilla à cause de leurs demandes trop importantes : processus d'approbation des patches (inadmissible dans le cas de patches de sécurité, et ceci n'est qu'une des pièces de l'incompétence totale de Mozilla dans le domaine de la sécurité) et logo imposé à la licence non libre.
Sur le site de CUPS on peut lire : Apple Inc. has trademarked the Common UNIX Printing System, CUPS, and CUPS logo. These names and logos may be used freely in any direct port or binary distribution of CUPS. To use them in derivative products, please contract Apple Inc. for written permission. Our intention is to protect the value of these trademarks and ensure that any derivative product meets the same high-quality standards as the original.
Pour moi ça ressemble plus à Apache et il est plus que probable qu'Apple laisse les distributeurs tranquilles, contrairement à Mozilla.
Groan, ok ubuntu est moins fignolé que debian mais si il ya des problèmes majeurs les releases ne se font pas quand même...
Ah, parce que la release d'edgy ne s'est pas faite ? Première nouvelle...
1) les deadlines sont depasses car le client tire le prix vers le bas au max. Pas l'impression qu'il y ait grand monde qui tire quoi que ce soit vers le bas dans le cas de debian
Bah si justement, dunc-tank. Ils tirent la qualité vers le bas pour releaser plus vite. Le modèle Ubuntu, quoi.
Le but de ce projet est d'emmerder le plus possible dunk tank. Au moins on sait sur quelles bases on part et puis voila...
Dunc-tank nuit à la qualité de la distribution. Le but de ce projet est d'empêcher ça. À la fois en améliorant la qualité de la distribution par d'autres moyens, et en nuisant directement à dunc-tank. Ce qui a doublement réussi puisque de nouvelles méthodes de QA ont été inventées conduisant à une amélioration globale de la qualité, et parce que l'image de dunc-tank s'est cassée la gueule quand il est devenu évident que le retard serait supérieur à un mois.
Et Sam de conclure : « J'adore qu'un plan se déroule sans accroc. »
[^] # Le problème qui n’en est pas un
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 1.
J’ai déjà expliqué point par point en quoi tout ceci est un tissu d’absurdités : http://np237.livejournal.com/24790.html
Quant à juger que MDI se disperse en « futilités contestables », renseigne-toi 5 minutes sur ce qu’est Mono avant. Il n’existe aucun, je dis bien aucun, framework de développement libre qui soit à moitié aussi complet que Mono. Tant en termes d’environnement de développement, de qualité et quantité de bibliothèques disponibles, de cohérence, que de nombre de langages supportés.
Il ne t’est jamais passé par la tête que si les gens l’utilisent, ce n’est pas par « besoin frénétique » mais tout simplement parce que c’est plus efficace de développer avec Mono ? Plus efficace même que de développer avec .Net, vu que Mono est plus performant et dispose de bibliothèques (comme Qt# et Gtk# en particulier).
[^] # Re: Pour Gnomono, ça n'est pas prêt de s'arranger !
Posté par Jar Jar Binks (site web personnel) . En réponse au journal Windowmaker toujours le WM favori. Évalué à 1.
Merci de pallier enfin à ce manque flagrant.
[^] # Re: Architecture vs paquet
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Deux cœurs BSD chez Debian. Évalué à 3.
[^] # Re: Licence GPLv3 ou BSD ?
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Deux cœurs BSD chez Debian. Évalué à 8.
Sachant de plus que la licence BSD est compatible avec la GPL v3…
[^] # Re: Note de mise à jour un peu dégueulasse avec Mozilla
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 5.
Que le mainteneur Debian d’OpenSSL ait complètement merdé, y compris dans la gestion de l’alerte, c’est évident. Mais pour avoir vu comment l’équipe de sécurité a rattrapé le coup, je pense que tu généralises beaucoup trop vite. Et des tanches bien pires que lui, il y en a dans les équipes de développement de toutes les distributions.
Bref, ce problème a touché Debian comme il aurait pu toucher n’importe qui. S’il avait touché Red hat, serais-tu aujourd’hui à cracher sur Red hat ? Est-ce que ça empêcherait leur équipe de sécurité de faire elle aussi un super boulot ? Contrairement aux fanboys de ton genre, la réaction des développeurs des autres distributions n’a pas été “Ololol Debian pwned” mais plutôt “Ouf, c’était pas nous”. Je t’assure que dans une telle situation, personne n’a intérêt à se la ramener (à part ceux qui ont r00té des machines grâce à la faille).
Enfin, si ça avait touché un logiciel propriétaire, crois-tu que tu serais seulement au courant de l’existence d’un tel problème ? Au passage, comme l’a fait très justement remarquer Schneier, ce genre de problèmes n’est pas nouveau, il est même souvent intentionnel, et il y a encore probablement beaucoup de logiciels affectés.
[^] # Re: Note de mise à jour un peu dégueulasse avec Mozilla
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 1.
[^] # Re: Le Release Manager de Debian est un froussard!
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 2.
[^] # Re: Finalement je suis content qu'elle sorte
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 1.
[^] # Re: Note de mise à jour un peu dégueulasse avec Mozilla
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 1.
Écrire du code sécurisé et gérer le flux des problèmes de sécurité sont deux choses bien différentes. Les développeurs d’OpenSSH ne sont bons que pour l’une des deux problématiques - note, c’est toujours une de plus que pour ceux de Moizilla.
[^] # Re: Note de mise à jour un peu dégueulasse avec Mozilla
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à -1.
Regardez plutôt comment ça fonctionne pour des projets avec un bon processus de développement, comme Python, KDE ou GNOME. Là, pas besoin que les développeurs passent trois plombes à chercher où se trouve le correctif, et encore plus à tester toutes les mises à jour dont il dépend.
[^] # Re: Je me lance ou pas? (et ce n'est pas un troll)
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à -6.
[^] # Re: Je me lance ou pas? (et ce n'est pas un troll)
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 5.
[^] # Re: Mesures qui seront prises ?
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 3.
Les problèmes liés au support de nombreuses architectures provoquent ponctuellement des problèmes avec testing, qui n’ont pas d’impact sur le développement dans unstable. Donc dire que ça retarde les releases, c’est vrai dans une faible mesure, mais dire que ça retarde l’inclusion de fonctionnalités, c’est juste étaler ton ignorance.
[^] # Re: Mesures qui seront prises ?
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 1.
Merci pour ce moment de franche rigolade, ça fait du bien.
[^] # Re: Mesures qui seront prises ?
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 3.
Pour ta gouverne, non seulement supporter plein d’architectures ne représente quasiment rien en temps pour les mainteneurs (ça occupe surtout les porteurs), mais cela permet un travail de QA et de nettoyage du code qui n’aurait jamais lieu sinon.
Par exemple, un bug magnifique trouvé dans XPCOM pas plus tard qu’aujourd’hui : https://bugzilla.mozilla.org/show_bug.cgi?id=434190
De manière générale, je ne sais pas d’où tu sors ta vision du monde du libre, mais tes commentaires sont tout simplement pathétiques.
[^] # Re: Limite du développement bénévole
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 4.
C’est un problème dans la façon dont le paquet est distribué sur les miroirs, mais en interne les mainteneurs utilisent git et tous les patches sont correctement séparés dans la version distribuée sur git.debian.org.
Notons aussi comme il est étrange de voir Debian qui gueule après OpenSSL qui n'a pas audité ses patchs, alors que Debian ne voulait pas que Mozilla les audites ou n'a pas fait (encore ?) ce qu'a demandé Mozilla pour les auditer.
Personne n’a rien contre de l’audit de patches, au contraire. Par contre, une licence qui empêche de publier lesdits patches avant qu’ils aient été audités par une entité sur laquelle tu n’as aucun contrôle, ça c’est un problème.
[^] # Re: Troll à gogo
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Epiphany va migrer vers du 100% WebKit. Évalué à 2.
Ils s’arrachent les cheveux. D’où l’abandon.
Gecko aussi est fait pour être réutilisé...
Non, trois fois non. Gecko est conçu pour être le moteur de Firefox. Le reste, c’est de la seconde zone.
Gecko aussi. Gecko repose aussi sur cairo, gtk et cie... D'ailleurs l'un des liens le précise. Bref, ce n'est pas un avantage à webkit.
Webkit dispose d’une API entièrement basée sur GObject, qui permet de l’intégrer directement au système de classes de GNOME. Alors que Gecko nécessite l’utilisation de couches d’interface tordues en C++ et d’une quantité de code de glu qui ne fait que croître avec le temps. Quant à parler de réutilisation de GTK+ Gecko, c’est à peu près autant le cas que pour Openoffice. Utilisé oui, mais très mal utilisé, d’où les lenteurs terribles du port X11 par rapport au port Windows, par exemple.
En quoi Gecko ne le serait pas ?
Parce que Gecko est une usine à gaz, et que contrairement aux idées reçues, les développeurs de GNOME cherchent à alléger leurs applications.
[^] # Re: Persch
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Epiphany va migrer vers du 100% WebKit. Évalué à 1.
[^] # Re: Re:
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Epiphany va migrer vers du 100% WebKit. Évalué à 5.
Non. Le bon fonctionnement de gtkembedmoz est la dernière des priorités des développeurs. C’est déjà un miracle d’arriver à faire fonctionner quelque chose comme Epiphany dessus, et ça marche grâce à quantité de bidouilles immondes.
# Encore des bêtises
Posté par Jar Jar Binks (site web personnel) . En réponse à la dépêche Apple rachète CUPS. Évalué à 7.
Ce n'est pas tout-à-fait vrai, et surtout j'ai lu tout et n'importe quoi dans les commentaires.
Ce type de clause existe aussi pour la marque Apache. Pourtant, Debian distribue des paquets Apache modifiés qui portent le nom Apache (ce qu'au passage, Redhat a refusé). Il existe un accord qui permet à Debian de distribuer des paquets modifiés de manière raisonnable sans demander l'accord de la fondation Apache. Cet accord n'a pas été possible avec Mozilla à cause de leurs demandes trop importantes : processus d'approbation des patches (inadmissible dans le cas de patches de sécurité, et ceci n'est qu'une des pièces de l'incompétence totale de Mozilla dans le domaine de la sécurité) et logo imposé à la licence non libre.
Sur le site de CUPS on peut lire : Apple Inc. has trademarked the Common UNIX Printing System, CUPS, and CUPS logo. These names and logos may be used freely in any direct port or binary distribution of CUPS. To use them in derivative products, please contract Apple Inc. for written permission. Our intention is to protect the value of these trademarks and ensure that any derivative product meets the same high-quality standards as the original.
Pour moi ça ressemble plus à Apache et il est plus que probable qu'Apple laisse les distributeurs tranquilles, contrairement à Mozilla.
[^] # Re: C'est qui Etch
Posté par Jar Jar Binks (site web personnel) . En réponse au journal Etch sous la barre des 100. Évalué à 2.
[^] # Re: C'est qui Etch
Posté par Jar Jar Binks (site web personnel) . En réponse au journal Etch sous la barre des 100. Évalué à 4.
Et si tu arrêtais de brasser du vent ?
[^] # Re: C'est qui Etch
Posté par Jar Jar Binks (site web personnel) . En réponse au journal Etch sous la barre des 100. Évalué à 2.
Il a tagué le bug "confirmed", je ne vois pas ce qu'il te faut de plus.
[^] # Re: C'est qui Etch
Posté par Jar Jar Binks (site web personnel) . En réponse au journal Etch sous la barre des 100. Évalué à 2.
Ah, parce que la release d'edgy ne s'est pas faite ? Première nouvelle...
[^] # Re: C'est qui Etch
Posté par Jar Jar Binks (site web personnel) . En réponse au journal Etch sous la barre des 100. Évalué à 7.
Bah si justement, dunc-tank. Ils tirent la qualité vers le bas pour releaser plus vite. Le modèle Ubuntu, quoi.
Le but de ce projet est d'emmerder le plus possible dunk tank. Au moins on sait sur quelles bases on part et puis voila...
Dunc-tank nuit à la qualité de la distribution. Le but de ce projet est d'empêcher ça. À la fois en améliorant la qualité de la distribution par d'autres moyens, et en nuisant directement à dunc-tank. Ce qui a doublement réussi puisque de nouvelles méthodes de QA ont été inventées conduisant à une amélioration globale de la qualité, et parce que l'image de dunc-tank s'est cassée la gueule quand il est devenu évident que le retard serait supérieur à un mois.
Et Sam de conclure : « J'adore qu'un plan se déroule sans accroc. »