et regardez dans Help/About Firefox ce qu'il y a à propos de The Charlton Company...
Le problème (ou plutôt la discussion) est plus entre la MoFo et Debian: The foundation is facing criticism from developers of the Debian Linux distribution (which distributes a version of Firefox)
Si tes clients l'acceptent, ce serait une super idée, à mon avis. A mon avis c'est tout à fait dans la bonne philosophie ("contribute back", ça marche en code, en trads, en bug-reports, et pourquoi pas en monnaie sonnante et trébuchante!).
Recompiler un noyau a un intérêt assez grand sur les iBook G4: support de la mise en veille correct (sans oops USB), corrections du code cpufreq, et pas mal d'autres bugfixes. A vrai dire le 2.6.12-rc4 est l'un des premiers noyaux stables sur iBook G4 (depuis celui qui intègre les premiers patches de mise en veille, du moins).
Est-ce une manière polie de dire que l'auteur principal de Sylpheed a presque ignoré le projet Sylpheed Claws quant à d'éventuelles améliorations/nouveautés ?
C'est un peu l'impression que j'ai, mais comme je n'étais pas là à la création du projet je peux me tromper.
Par exemple, j'utilisais depuis peu Sylpheed 1.9.9 en GTK+2 [1] et j'ai été étonné de constater que le port GTK+2 avait été pris du projet sylpheed-gtk2 [2] - moins connu comparé à Sylpheed Claws - alors que Sylpheed Claws supporte GTK+2. À moins que le support GTK+2 de Sylpheed Claws provient aussi du projet sylpheed-gtk2 ?
Initialement, oui, c'est aussi Takuro Ashie qui a fait le premier (gros) patch gtk2 pour Claws, et qui l'a maintenu pendant 6 mois. Ensuite, il s'est concentré sur sylpheed-gtk2. Reprendre le support gtk2 de Claws aurait représenté plus de travail pour Hiroyuki que reprendre celui de sylpheed-gtk2, vu la divergence des sources :)
Pas vraiment. Le truc c'est que de l'avis de tous il n'y a pas de "chef du projet". les Project Admins ont juste droit à plus de tâches ingrates, pas à un vote plus important.
Mais effectivement l'un des initiateurs du projet, par son immobilisme (vis-à-vis de gtk2) et sa manie de réécrire en c++ des trucs qui marchaient , m'a saoûlé très fort, j'ai failli forker, du coup il est parti, du coup ça c'est débloqué.
> Au risque de passer pr un vieux conservateur ou un complet ignare,
> l'ajout de toutes ces fonctionnalités et le passage en gtk2 ne
> risquent-ils pas de faire perdre à sylpheed-claws son âme
Non, on essaye toujours de faire efficace. La plupart des features ne se mettent pas en travers du chemin d'une utilisation "efficace". De toutes façons cette "âme" n'est pas dûe à des micro-optimisations de ci de là mais surtout à un mode d'utilisation (le plus possible de raccourcis, confirmations "intelligentes", ...)
En fait, je le trouve toujours aussi réactif qu'avant, et il s'est même amélioré ces derniers mois je pense (au niveau du cache j'imagine - Colin, tu confirmes ou bien j'ai tripé ?).
Tu as tripé :-) le cache a été un chouïa optimisé c'est vrai, mais pas de quoi voir la différence. Le plus visible est fait dans l'interface (comme par exemple locker les màj graphiques des arbres avant de déplacer des mails pour éviter N refresh, etc.)
La seule petite lenteur que je vois c'est quand j'ouvre un dossier de + de 10.000 ou 20.000 mails, y'a ~2 secondes de "Tri du sommaire" qui me font passagèrement trépigner
Moi aussi; en même temps, c'est gros 20000 mails :)
(enfin je vois pas pourquoi c'est à nouveau trié si je l'ai déjà consulté avec la même présentation plus tôt)
Pour une raison de place mémoire... Imagine si on gardait le résultat du threading de N dossiers à 10000+ mails :)
Oui. En fait la glibc ne détecte pas toute seule le changement de DNS. La 1.9.9 devrait marcher mieux dans ton cas (J'ai ajouté ça parce que j'avais le même problème).
D'après ce que j'ai compris, git ne fait pas de réseau (contrairement à CVS, BK, ou d'autres), mais permet de merger rapidement des patches de différentes sources - qui sont donc reçus par mail, je crois.
Mais il faut dire que c'est assez pointu comme concepts, alors ne prenez pas ce que je dis comme argent comptant.
Et pourquoi faut-il un getsionnaire décentralisé pour le versionning du noyau ?
Parce qu'il y a des centaines de contributeurs; la plupart des contributeurs importants sont spécialisés dans certains sous-systèmes, ils ont ainsi la possibilité d'avoir un noyau normal, sans souffrir des bugs bleeding-edge du sous-système d'à côté, tout en développant dans leur coin. Lorsqu'ils considèrent leur travail stable (merge-able dans l'arbre de Linus), Torvalds n'a qu'à "tirer" les patches de gauche et de droite.
La meilleure solution reste, de loin, la destruction de la terre par des vaisseaux spatiaux de guerre afin de construire, comme chacun le sait, une déviation intergalactique.
Il ne le cite même pas, honte sur lui. ;)
Pas trop, oui. Sylpheed-Claws a reçu son premier don il y a quelques semaines: $5. Si on enlève la comm' de paypal et la comm' de Sourceforge, reste $3.54, à se partager entre 19 développeurs :)
# Avant de troller
Posté par Colin Leroy (site web personnel) . En réponse au journal FireSomething. Évalué à 4.
http://weblogs.mozillazine.org/gerv/archives/008347.html(...)
http://www.firefox.com/(...)
et regardez dans Help/About Firefox ce qu'il y a à propos de The Charlton Company...
Le problème (ou plutôt la discussion) est plus entre la MoFo et Debian:
The foundation is facing criticism from developers of the Debian Linux distribution (which distributes a version of Firefox)
# titre
Posté par Colin Leroy (site web personnel) . En réponse au journal Une idée parmis tant d'autre. Évalué à 1.
[^] # Re: Prise de tête
Posté par Colin Leroy (site web personnel) . En réponse au journal ratdvd mieux qu'XVID et DivX réunis.... Évalué à 10.
[^] # Re: Mouahahahaha
Posté par Colin Leroy (site web personnel) . En réponse au journal Ketady, de l'art d'exploiter l'internaute !. Évalué à 2.
oops
[^] # Re: pabôhh
Posté par Colin Leroy (site web personnel) . En réponse au journal Evolution bientôt sous Windows (screenshots). Évalué à 3.
[^] # Re: wintosh et macindows sont dans un bateau (qui prend l'eau)...
Posté par Colin Leroy (site web personnel) . En réponse au journal Nouvelle campagne de pub de la pomme. Évalué à 2.
[^] # Re: wintosh et macindows sont dans un bateau (qui prend l'eau)...
Posté par Colin Leroy (site web personnel) . En réponse au journal Nouvelle campagne de pub de la pomme. Évalué à 4.
Je parie que ça fonctionnera deux mois au plus après la sortie du modèle en question.
Never Underestimate BenH.
[^] # Re: update : pas d'openfirmware
Posté par Colin Leroy (site web personnel) . En réponse au journal S Jobs : ce grand comique. Évalué à 3.
[^] # Re: tous ca?
Posté par Colin Leroy (site web personnel) . En réponse au journal Nouvelle annonce de Nokia. Évalué à 9.
Ah là là, qu'est-ce que c'est que cette mode de toujours râler...
# noexec insuffisant
Posté par Colin Leroy (site web personnel) . En réponse au journal Linux, les failles, les virus et le grand public. Évalué à 10.
/bin/bash ./virus.sh
suffira. Soit c'est un exécutable ELF et
/lib/ld-linux.so.2 ./virus
fonctionnera.
(N'essayez pas le chmod -x /lib/ld-linux.so.2, c'est une mauvaise idée qui vous fera sortir le CD rescue).
# perturbations électromagnétiques?
Posté par Colin Leroy (site web personnel) . En réponse au journal Bit flippé, bit flippant. Évalué à 3.
si ça t'es arrivé vendredi ou ce week-end ça explique peut-être...
[^] # Re: utiliser des noyaux précompilés ?
Posté par Colin Leroy (site web personnel) . En réponse au journal Compilation d'un kernel pour iBook. Évalué à 3.
[^] # Re: Liens Sylpheed / Sylpheed Claws
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Sylpheed-Claws: Changement de direction. Évalué à 4.
Est-ce une manière polie de dire que l'auteur principal de Sylpheed a presque ignoré le projet Sylpheed Claws quant à d'éventuelles améliorations/nouveautés ?
C'est un peu l'impression que j'ai, mais comme je n'étais pas là à la création du projet je peux me tromper.
Par exemple, j'utilisais depuis peu Sylpheed 1.9.9 en GTK+2 [1] et j'ai été étonné de constater que le port GTK+2 avait été pris du projet sylpheed-gtk2 [2] - moins connu comparé à Sylpheed Claws - alors que Sylpheed Claws supporte GTK+2. À moins que le support GTK+2 de Sylpheed Claws provient aussi du projet sylpheed-gtk2 ?
Initialement, oui, c'est aussi Takuro Ashie qui a fait le premier (gros) patch gtk2 pour Claws, et qui l'a maintenu pendant 6 mois. Ensuite, il s'est concentré sur sylpheed-gtk2. Reprendre le support gtk2 de Claws aurait représenté plus de travail pour Hiroyuki que reprendre celui de sylpheed-gtk2, vu la divergence des sources :)
[^] # Re: Très très bien, et félicitation
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Sylpheed-Claws: Changement de direction. Évalué à 5.
Mais effectivement l'un des initiateurs du projet, par son immobilisme (vis-à-vis de gtk2) et sa manie de réécrire en c++ des trucs qui marchaient , m'a saoûlé très fort, j'ai failli forker, du coup il est parti, du coup ça c'est débloqué.
Pour les amateurs de Santa Barbara du logiciel libre vous pouvez voir l'histoire longue et les deux points de vue sur
http://www.colino.net/wordpress-1.5/archives/2005/02/17/sylpheed-cl(...)
http://www.colino.net/wordpress-1.5/archives/2005/02/17/sylpheed-cl(...)
http://reboot.animeirc.de/sylpheed/(...)
[^] # Re: et l'essentiel?
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Sylpheed-Claws: Changement de direction. Évalué à 3.
> l'ajout de toutes ces fonctionnalités et le passage en gtk2 ne
> risquent-ils pas de faire perdre à sylpheed-claws son âme
Non, on essaye toujours de faire efficace. La plupart des features ne se mettent pas en travers du chemin d'une utilisation "efficace". De toutes façons cette "âme" n'est pas dûe à des micro-optimisations de ci de là mais surtout à un mode d'utilisation (le plus possible de raccourcis, confirmations "intelligentes", ...)
En fait, je le trouve toujours aussi réactif qu'avant, et il s'est même amélioré ces derniers mois je pense (au niveau du cache j'imagine - Colin, tu confirmes ou bien j'ai tripé ?).
Tu as tripé :-) le cache a été un chouïa optimisé c'est vrai, mais pas de quoi voir la différence. Le plus visible est fait dans l'interface (comme par exemple locker les màj graphiques des arbres avant de déplacer des mails pour éviter N refresh, etc.)
La seule petite lenteur que je vois c'est quand j'ouvre un dossier de + de 10.000 ou 20.000 mails, y'a ~2 secondes de "Tri du sommaire" qui me font passagèrement trépigner
Moi aussi; en même temps, c'est gros 20000 mails :)
(enfin je vois pas pourquoi c'est à nouveau trié si je l'ai déjà consulté avec la même présentation plus tôt)
Pour une raison de place mémoire... Imagine si on gardait le résultat du threading de N dossiers à 10000+ mails :)
[^] # Re: [...] le rafraîchissement des paramètres réseau [...]
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Sylpheed-Claws: Changement de direction. Évalué à 4.
[^] # Re: ne marche pas par rapport à x86 :
Posté par Colin Leroy (site web personnel) . En réponse au journal Linux et l'architecture PPC (ibook). Évalué à 1.
bon reste l'usb mais j'accorde que c'est un peu nul :/
En fait, ça marche très bien avec les sticks dont le driver est intégré au noyau (zd1021 ici, avec un stick Peabird PEAB-WL-USB).
[^] # Re: ne marche pas par rapport à x86 :
Posté par Colin Leroy (site web personnel) . En réponse au journal Linux et l'architecture PPC (ibook). Évalué à 1.
Les iBooks ont pas de slot pcmcia donc ça résoud la question :)
Sinon, pcmcia (pc-card) est un standard et du moment que le driver est bien codé niveau endianness, il n'y a pas de problème.
[^] # Re: Moi le nouveau
Posté par Colin Leroy (site web personnel) . En réponse au journal Linux et l'architecture PPC (ibook). Évalué à 8.
Ça marche aussi avec le DRI pour peu que tu ajoutes l'Option "AgpMode" "4" dans le xorg.conf.
[^] # Re: coucou
Posté par Colin Leroy (site web personnel) . En réponse au journal GNU/Linuxiens à Colomiers, Blagnac, Tournefeuille, Toulouse Ouest ?. Évalué à 1.
[^] # Re: précisions ?
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Linus développe un remplaçant original à BitKeeper. Évalué à 6.
Mais il faut dire que c'est assez pointu comme concepts, alors ne prenez pas ce que je dis comme argent comptant.
[^] # Re: siffler
Posté par Colin Leroy (site web personnel) . En réponse au journal Siffler n'est pas jouer. Évalué à 8.
[^] # Re: remplacement?
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. Évalué à 2.
Parce qu'il y a des centaines de contributeurs; la plupart des contributeurs importants sont spécialisés dans certains sous-systèmes, ils ont ainsi la possibilité d'avoir un noyau normal, sans souffrir des bugs bleeding-edge du sous-système d'à côté, tout en développant dans leur coin. Lorsqu'ils considèrent leur travail stable (merge-able dans l'arbre de Linus), Torvalds n'a qu'à "tirer" les patches de gauche et de droite.
# HHGG
Posté par Colin Leroy (site web personnel) . En réponse au journal Pour détruire la terre. Évalué à 4.
Il ne le cite même pas, honte sur lui. ;)
[^] # Re: Pas complètement vrai
Posté par Colin Leroy (site web personnel) . En réponse au journal OSS et donations. Évalué à 3.
Faut pas compter dessus, quoi...