Curieusement je ne greppe rien d'approprié avec "leak" ou "audio" ou "burn" ou "bio_". On dirait que le bug de memory leak à la gravure de CDs audio n'a pas été corrigé. Étant donné qu'il y a des patchs, attendent-ils une meilleure solution?
(Ou bien j'ai mal vu).
Si quelqu'un a des infos, elles sont les bienvenues.
* J'espère qu'il restera en GTK1 ne serait-ce que pour garder sa 'nervosité'. Et honnêtement je ne vois pas ce qu'apporterais GTK2 sinon de la lourdeur.
Contrairement à ce à quoi on peut s'attendre, la branche GTK2 est plus réactive. En effet, il n'y a plus besoin de widgets persos pour le GtkExtTree (la liste de message) ni pour le GtkSText (pour la fenêtre de composition).
ça c'est autre chose, c'est un port de Sylpheed vers gtk2... Pas sylpheed-claws :)
Ah oui, autre chose à propos de la stabilité du CVS: on synchronise avec la branche gtk1 à la main, et on teste à chaque fois ; il y a assez peu de modifs gtk2-only ces derniers temps : c'est donc un CVS un peu moins chaotique qu'il pourrait l'être...
Mmh, on ne fait pas de snapshots... Mais je pourrais faire des tarballs non-officielles, peut-être...
Enfin, il faut savoir qu'autant 'bleeding-edge' que soie SC, le pire qu'il puisse arriver, c'est de devoir rescanner tes dossiers: le format MH des boîtes (un fichier/mail) fait que c'est très dur de détruire des données; ça n'est pas encore arrivé, à ma connaissance.
Merci pour tes encouragements!
Plus que ça, j'ai un problème à graver des CDs (audio): le système prend toutes les ressources dispos, swappe comme un fou, et finit par mourir (ou équivalent, même un ssh n'aboutit pas). Le problème n'existait pas avec le 2.6.8-rc2 sur lequel je retourne.
Uh? Tu veux dire quoi par "multi-tâche"? multi-thread?
Sinon je suppose que tu veux parler de Sylpheed-claws, vu que Sylpheed n'a pas encore, à ma connaissance, de plugins.
Pour info, et on l'a répété beaucoup, le multi-threading n'est pas la panacée pour résoudre les problèmes d' I/O bloquante - principalement du fait de toute la synchronisation inter-thread qui doit être faite pour éviter toutes les race-conditions qui arrivent sinon. De plus, plusieurs threads dans une appli GTK signifie problèmes à très court terme si jamais plus d'un thread fait du GTK. Ce qui complique encore la tâche.
(Evidemment, ç'aurait été plus facile de traiter ces problèmes si sylpheed avait été multi-thread à la naissance).
Tout ça pour dire que d'autres solutions existent, les systèmes de rappel de callback quand des données sont prêtes (g_io_channels, ...) et tous les systèmes différents de poll de socket (poll, select) (qui ont chacun leurs avantages et inconvénients. Dans S-C c'est des systèmes de callbacks, principalement, qui sont utilisés.
Enfin, le débloquage des I/O dans sylpheed a beaucoup progressé ces derniers temps; le dernier appel bloquant que j'aie trouvé, SSL_connect(), qui faisait bloquer à l'initialisation, vient d'être 'débloqué' (grâce à un micro thread dont le cycle de vie est l'appel de cette fonction). Ce sera dans la prochaine release.
est ce que GNU sont compatibles et utilisables avec le droit français
Tu voulais dire GNU GPL je suppose.
Ses termes ne sont pas entièrement compatibles avec le droit français : trop grande exonération de responsabilité, par exemple. D'autre part seuls les contrats rédigés en langue française sont valides en droit français.
Sauf si tu es un hébergeur web, je ne penses pas que cette faille soit vraiment critique pour toi
Si, cette faille permet [probablement] d'exécuter du code arbitraire à partir d'une image png. Elle est donc de classe 'remote' puisque les navigateurs chargent les png à partir de sites distants, auxquels on ne peut faire confiance.
La gravité de la chose est mitigée par le fait que cette faille ne permet pas une escalade de privilèges (passage root), le code s'exécute avec les droits de l'utilisateur qui a chargé l'image.
create these artificial barriers to solving problems
créez ces barrières artificielles pour résoudre des problèmes
Ce serait plutôt créez des barrières artificielles à la résolution de problèmes: ces barrières artificielles compliquent la résolution de problèmes.
(je sais, ma traduction est un peu moche, ...)
on dirait que tu as compris de travers la facture négative que tu as reçue... Ce n'était pas un avoir, juste une trace papier du remboursement qu'ils allaient te faire :)
"Mes drivers sont pour 2.6.7 et je suis en 2.6.4 !! Argh !!"
J'imagine que tu parles de compatibilité des APIs (donc compatibilité à la compilation). Peut-être qu'elle n'y sera plus forcément.
Ce n'est pas forcément un mal, car de subtils changements au plus profond des APIs peut déjà "casser" un driver, mais à l'exécution plutôt qu'à la compilation. Cdc-acm, le driver de modem GPRS usb, m'a fait ce coup au 2.6.4 et 2.6.5.
Moins le problème est gros, plus il est difficile à trouver, donc une erreur à la compilation vaut mieux, pour moi, qu'un Oops sorti de nulle part...
Evidemment on va parler des drivers propriétaires, mais ils sont déjà cassés (à l'exécution) de temps à autre avec le modèle actuel (nVidia et le 4K_STACK, les drivers linuxant n'ont pas encore tourné sans Oops sur toute la série des 2.6.* que j'ai utilisé, ...), donc ça ne sera pas réellement pire.
C'est surtout qu'elle est débile. Des affirmations ironiquement négativisées et non vérifiées n'ont jamais fait une bonne argumentation. Google sur son "pseudo" et tu pourras suspecter qu'il ne s'agit pas d'un pseudo.
Seulement les clauses contraires au droit sont non valables ("réputée non écrite"). Une clause invalide, ou même plusieurs, n'annulent pas l'intégralité du contrat.
# CDs audio?
Posté par Colin Leroy (site web personnel) . En réponse au journal Sortie du noyau 2.6.9-rc1. Évalué à 2.
(Ou bien j'ai mal vu).
Si quelqu'un a des infos, elles sont les bienvenues.
# Pas mal...
Posté par Colin Leroy (site web personnel) . En réponse au journal Le windows du pauvre pour contrer linux. Évalué à 4.
Ils auraient dû aussi empêcher l'installation de logiciels. Ça aurait eu l'avantage de sécuriser le machin.
Belle pub pour les logiciels libres, d'une certaine façon...
[^] # Re: La prise en compte des citations est toujours boguées...
Posté par Colin Leroy (site web personnel) . En réponse au journal Sortie de Sylpheed-Claws 0.9.12a. Évalué à 2.
En gros Sylpheed met le souk dans une citation dès qu'on alterne entre les >> et les > > (notez l'espace entres les deux symboles).
Mmh, j'y avais jeté un oeil et rien trouvé...
P.S. : le rapatriement partiel par POP3 c'est génial ! ça faisait un moment que je l'attendais celui-là pour lutter contre les virus !
Merci !
:°)
[^] # Re: sylpheed-claws
Posté par Colin Leroy (site web personnel) . En réponse au journal Sortie de Sylpheed-Claws 0.9.12a. Évalué à 3.
Contrairement à ce à quoi on peut s'attendre, la branche GTK2 est plus réactive. En effet, il n'y a plus besoin de widgets persos pour le GtkExtTree (la liste de message) ni pour le GtkSText (pour la fenêtre de composition).
Au final, ça va plus vite en gtk2 :oP
[^] # Re: Bof cet article...
Posté par Colin Leroy (site web personnel) . En réponse au journal Sortie de Sylpheed-Claws 0.9.12a. Évalué à 2.
Ah oui, exact...
Sylpheed-Claws est un client mail qui déchire ;-)
[^] # Re: Que du bon quoi, comme d'hab'...
Posté par Colin Leroy (site web personnel) . En réponse au journal Sortie de Sylpheed-Claws 0.9.12a. Évalué à 5.
Ah oui, autre chose à propos de la stabilité du CVS: on synchronise avec la branche gtk1 à la main, et on teste à chaque fois ; il y a assez peu de modifs gtk2-only ces derniers temps : c'est donc un CVS un peu moins chaotique qu'il pourrait l'être...
[^] # Re: Que du bon quoi, comme d'hab'...
Posté par Colin Leroy (site web personnel) . En réponse au journal Sortie de Sylpheed-Claws 0.9.12a. Évalué à 5.
Enfin, il faut savoir qu'autant 'bleeding-edge' que soie SC, le pire qu'il puisse arriver, c'est de devoir rescanner tes dossiers: le format MH des boîtes (un fichier/mail) fait que c'est très dur de détruire des données; ça n'est pas encore arrivé, à ma connaissance.
Merci pour tes encouragements!
[^] # Re: Le bug NFS
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Linux 2.6.8, suivi de près par Linux 2.6.8.1. Évalué à 2.
if ((res=nfs_check_flags(filp->f_flags) != 0)
...
ça fait une notation un peu lourde, du coup.
[^] # Re: Problème cdrecord.prodvd
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Linux 2.6.8, suivi de près par Linux 2.6.8.1. Évalué à 4.
http://lkml.org/lkml/2004/8/14/103(...)
Oui, c'est moi ;)
[^] # Re: Problème cdrecord.prodvd
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Linux 2.6.8, suivi de près par Linux 2.6.8.1. Évalué à 4.
# MacSoup
Posté par Colin Leroy (site web personnel) . En réponse au journal Thread Arcs. Évalué à 5.
http://news.cis.dfn.de/images/screenshots/soup0250.gif(...)
Le treeview remplit quand même bien son rôle je trouve.
[^] # Re: tentative spamassassin + sylpheed [complètement HS]
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche SpamAssassin devient un projet Apache, et corrige une faille de sécurité. Évalué à 6.
Uh? Tu veux dire quoi par "multi-tâche"? multi-thread?
Sinon je suppose que tu veux parler de Sylpheed-claws, vu que Sylpheed n'a pas encore, à ma connaissance, de plugins.
Pour info, et on l'a répété beaucoup, le multi-threading n'est pas la panacée pour résoudre les problèmes d' I/O bloquante - principalement du fait de toute la synchronisation inter-thread qui doit être faite pour éviter toutes les race-conditions qui arrivent sinon. De plus, plusieurs threads dans une appli GTK signifie problèmes à très court terme si jamais plus d'un thread fait du GTK. Ce qui complique encore la tâche.
(Evidemment, ç'aurait été plus facile de traiter ces problèmes si sylpheed avait été multi-thread à la naissance).
Tout ça pour dire que d'autres solutions existent, les systèmes de rappel de callback quand des données sont prêtes (g_io_channels, ...) et tous les systèmes différents de poll de socket (poll, select) (qui ont chacun leurs avantages et inconvénients. Dans S-C c'est des systèmes de callbacks, principalement, qui sont utilisés.
Enfin, le débloquage des I/O dans sylpheed a beaucoup progressé ces derniers temps; le dernier appel bloquant que j'aie trouvé, SSL_connect(), qui faisait bloquer à l'initialisation, vient d'être 'débloqué' (grâce à un micro thread dont le cycle de vie est l'appel de cette fonction). Ce sera dans la prochaine release.
[^] # Re: Manque
Posté par Colin Leroy (site web personnel) . En réponse au sondage Citation. Évalué à 4.
JC van Damme?
[^] # Re: Mais alors quoi ?
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Trop de licences libres ?. Évalué à 4.
Tu voulais dire GNU GPL je suppose.
Ses termes ne sont pas entièrement compatibles avec le droit français : trop grande exonération de responsabilité, par exemple. D'autre part seuls les contrats rédigés en langue française sont valides en droit français.
[^] # Re: Distribution presque offert
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Revue de Presse - été 2004 (suite). Évalué à 4.
[^] # Re: Faille libpng
Posté par Colin Leroy (site web personnel) . En réponse au journal Faille libpng. Évalué à 2.
Et les comptes/prefs mail aussi... Terrible :-S
[^] # Re: Faille libpng
Posté par Colin Leroy (site web personnel) . En réponse au journal Faille libpng. Évalué à 6.
Si, cette faille permet [probablement] d'exécuter du code arbitraire à partir d'une image png. Elle est donc de classe 'remote' puisque les navigateurs chargent les png à partir de sites distants, auxquels on ne peut faire confiance.
La gravité de la chose est mitigée par le fait que cette faille ne permet pas une escalade de privilèges (passage root), le code s'exécute avec les droits de l'utilisateur qui a chargé l'image.
# Contresens dans la trad
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche IBM n'a pas l'intention de faire appliquer ses brevets dans le noyau Linux. Évalué à 9.
créez ces barrières artificielles pour résoudre des problèmes
Ce serait plutôt
créez des barrières artificielles à la résolution de problèmes: ces barrières artificielles compliquent la résolution de problèmes.
(je sais, ma traduction est un peu moche, ...)
[^] # Re: y'a t-il du mieux chez ATI ?
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Nouvelles versions des pilotes ATI et NVIDIA pour GNU/Linux. Évalué à -2.
ça marche avec les drivers libres ça...
# Avoir/Remboursement
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Remboursement chez Dell suite au refus du CLUF Windows. Évalué à 3.
(ça parle bien de remboursement ici: http://wiki.aful.org/EmailsGesteCommercial(...) , sinon pas besoin de ton RIB; donc ceci http://wiki.aful.org/AvoirDell(...) n'est pas un avoir...
Bien joué, en tout cas.
[^] # Re: Peut-être une exellente idée...
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche pam_usb 0.3.1 dans les bacs. Évalué à 2.
Genre, avec une scie? :)
[^] # Re: Question ?
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche Nouveau modèle de développement pour Linux. Évalué à 6.
J'imagine que tu parles de compatibilité des APIs (donc compatibilité à la compilation). Peut-être qu'elle n'y sera plus forcément.
Ce n'est pas forcément un mal, car de subtils changements au plus profond des APIs peut déjà "casser" un driver, mais à l'exécution plutôt qu'à la compilation. Cdc-acm, le driver de modem GPRS usb, m'a fait ce coup au 2.6.4 et 2.6.5.
Moins le problème est gros, plus il est difficile à trouver, donc une erreur à la compilation vaut mieux, pour moi, qu'un Oops sorti de nulle part...
Evidemment on va parler des drivers propriétaires, mais ils sont déjà cassés (à l'exécution) de temps à autre avec le modèle actuel (nVidia et le 4K_STACK, les drivers linuxant n'ont pas encore tourné sans Oops sur toute la série des 2.6.* que j'ai utilisé, ...), donc ça ne sera pas réellement pire.
[^] # Re: Industrie et culture...
Posté par Colin Leroy (site web personnel) . En réponse au journal Industrie et culture : coup de gueule. Évalué à 3.
C'est surtout qu'elle est débile. Des affirmations ironiquement négativisées et non vérifiées n'ont jamais fait une bonne argumentation. Google sur son "pseudo" et tu pourras suspecter qu'il ne s'agit pas d'un pseudo.
[^] # Re: Et sur les ordinateurs y a pas de solutions ?
Posté par Colin Leroy (site web personnel) . En réponse au journal La tartine. Évalué à 2.
Je voudrais pas te retourner le couteau dans la plaie, mais... on est mercredi ;-)
[^] # Re: Besoin de précisions...
Posté par Colin Leroy (site web personnel) . En réponse à la dépêche La justice allemande déclare la GNU GPL valide. Évalué à 9.