Thomas Preud'homme a écrit 48 commentaires

Garder le paquet dspam dans Debian c'est donner la fausse impression aux utilisateurs que le paquet est maintenu. Les utilisateurs vont ainsi s'attendre à ce qu'en cas de faille de sécurité ou de bug grave cela sera corrigé. Or cela fait près de 2 ans que c'est moi qui corrige ce genre de bogue car ce n'est plus actif en amont. J'avais déjà envoyé un mail il y a quelques mois pour m'enquérir de la situation et ce message du responsable des versions stables m'a confirmé dans l'idée que dspam devrait être retiré de Debian. Je ne me vois pas maintenir encore 3 ans de plus ce logiciel, devoir me plonger dans une base de code que je ne connais pour ainsi dire pas (enfin un tout petit petit peu à force de construire des rustines) et pondre un patch rapidement dès qu'un bogue important est rapporté.

Un exemple concret : il y a un bogue de sécurité que j'ai corrigé dans le paquet Debian lors du dernier gel de la suite testing de Debian et le patch n'a toujours pas été intégré en amont (il n'a pas non plus été refusé ou critiqué, juste plus ou moins ignoré). Et au cas où quelqu'un demande, non je ne suis pas suffisamment motivé pour reprendre le flambeau, désolé.

Cordialement,

Le mainteneur du paquet Debian de dspam.

Désolé de n'avoir pas répondu plus tôt. J'ai bien vu ton message et je vais voir pour changer le nom de l'option en --tccreldir. Merci pour l'information :)

Oui, je dirai que la vitesse de compilation est la priorité principale du projet. Pas dans le sens où tous les changements visent à améliorer cette vitesse — c'est plutôt rare en fait — mais dans le sens où c'est un des objectifs principaux du projet et donc un critère de décision important pour l'acceptation d'un changement. Cela dit, il n'est arrivé qu'une fois ou deux qu'un changement soit accepté car considéré trop lourd. TinyCC a plusieurs fonctionnalité mais c'est à mon avis sa rapidité et sa taille qui lui sont vraiment unique. On peut trouver les autres fonctionnalités ici ou là dans d'autres compilateurs. Il y a peut-être aussi le test de dépassement de bornes (bound checking) qui est assez atypique mais pas unique je pense.

Corcernant l'utilisation de TinyCC comme un moyen d'étendre une application je ne suis pas sûr exactement de comprendre la question mais je pense que la réponse est oui. Le projet TinyCC fournit une bibliothèque statique (libtcc.a) qui peut être incorporée dans un programme pour compiler du C à l'exécution. Il est donc tout à fait faisable de faire un compilateur à la volée (JIT) avec TinyCC et il me semble même que cela a été fait.

C/C++ correspond à la catégorie de la dépêche. En effet, TinyCC ne supporte pas C++ bien que des gens aient proposé de supporter au moins un sous-ensemble de la syntaxe C++ qui permet de compiler les projets de petite à moyenne taille n'utilisant pas toutes les constructions du C++. Il a été considéré que cela nécessiterait l'ajout de beaucoup de code et ralentirait donc la vitesse de compilation. Il a donc été décidé de ne pas intégrer le support de C++ dans TinyCC. Il reste possible cependant de faire un fork de TinyCC supportant le C++ et nous pouvons alors ajouter un lien vers ce fork pour les gens qui seraient intéressés.

Malheureusement, ils se sont inspiré des méthodes du libre mais pas de l'esprit, en tout cas pas complètement. Le Comment Faire commence par "Registering will pass on to you a royalty-free license for you to use this community developed patent pending design for non-commercial purposes."

Donc pas d'utilisation commerciale de ce machin. Cela signifie notament qu'il est impossible de fabriquer ces mécanismes pour les vendre à prix coûtant à ces voisins.

Dommage. Sympatique initiative néanmoins.

Il vaudrait mieux parler de projets propriétaire/privateur dans l'article. La GPL n'empêche en aucune façon les projets commerciaux.

À noter qu'il est assez facile de rajouter le support pour d'autres sites dans quvi. La documentation est très bien faite sur ce point, avec un tutorial pour montrer comment rajouter le support pour un site simple ou plus compliqué. Et vu la quantité de sites déjà supporté, il est également possible de s'inspirer du support déjà existants pour les autres sites.

À tel point, d’ailleurs, que les développeurs de Wordpress, sûrement envieux de l’une >des étoiles montantes du Web, avaient initialement nommé leur version 3.1 « Django », >avant de la renommer Reinhardt.

J'espère que c'est de l'ironie parce qui sinon il y a mécompréhension. Il s'agit d'une référence au célèbre guitariste de jazz manouche Django Reinhardt, rien de plus. Aucun rapport avec le framework Django si ce n'est que cela a peut-être été renommé pour éviter une possible confusion.

Le calcul est mauvais. Je ne puis répondre pour Windows mais en tout cas pour Linux et très probablement tous les BSD la mémoire n'augmente pas à la création d'un processus (fork). En effet, le processus fils partage tout le code et les données du processus père. Seulement lorsqu'il essaie de modifier une donnée, la donnée est dupliquer. Au final, la mémoire qu'occupera un processus correspond à ce qu'il apporte par rapport au processus père.

En l'occurence, les plugins occuperont une place assez petite car leur code et la mémoire dont ils ont besoin est petite. Au lieu d'avoir un firefox à 250 Mio tu auras peut-être un firefox à 100 Mio et le reste divisé en plusieurs plugins et onglets.

Pour le diaporama il y avait déjà HTML slidy. Cf http://formats-ouverts.org/blog/Web/2009/05/26

Je pense qu'il s'agit de "chemin du fichier" avec des lettres en moins

Sauf si le logiciel est sous licence AGPL

Non il y a une différence.

Réponse courte : dans un cas tu fais chier tes contacts et dans l'autre cas c'est toi qui est emmerdé.

Réponse longue : Si tu es chez toi et que la connexion lache tu peux toujours envoyer des messages hors ligne que le serveur enverra aux contacts en question quand la connexion remarchera. Si le serveur est distant tu ne peux juste rien faire (en tout cas sous gajim quand le serveur est injoignable aucun message ne peut être envoyé).

Et du point de vue des correspondant, il y a également une différence. Quand le serveur est chez toi ils recevront un remote-server-not-found (en tout cas sous gajim) et ne pourront pas envoyer de message hors ligne (en fait c'est légèrement différent du cas précédent, on peut envoyer un message mais il n'est jamais reçu et on reçoit l'erreur remote-server-not-found). Alors que si le serveur n'est pas chez toi tu apparais hors ligne et les messages hors ligne peuvent t'être envoyer.

…pour les OS libres dans l'embarqué ? Entre Symbian, Maemo, Android et consorts cela doit faire un sacré pourcentage. Ceci est vraiment une excellente nouvelle pour le libre.

Ou tout simplement si on veut ajouter un caractère (ou un octet) en plein milieu d'un fichier. Un éditeur de texte donne la sensation de pouvoir décaler les données mais write ne permet que de remplacer un caractère ou en ajouter à la fin. Plutôt que de chercher s'il est possible de ne faire que quelque remplacement de caractère il est plus simple de créer un nouveau fichier puis de faire un rename.

A priori le problème n'est pas tellement à la fermeture d'un programme mais plutôt les programmes qui font beaucoup d'écriture disque (ex base de données).

De plus il me semble plus approprié de faire une écriture asynchrone (il existe même une API posix pour cela) que de lancer un thread juste pour une écriture.

Je n'ai rien à reprocher à ce qui existe, à mon avis il faut tout garder. Par contre j'ai une petite suggestion d'amélioration à savoir faire une petite table des matières au début de l'article, à l'instar de ce qui est fait sur wikipedia. De manière générale n'importe quel gros article devrait avoir une petite table. Ici on pourrait imaginer un lien vers les 3 grosses sections que sont le récapitulatif des principales annonces de Linus concernant les RC, les nouveautés et les stats.

Pour le reste vraiment rien à redire. Les stats et les mails de Linus ne sont pas vraiment indispensables mais agréables à lire. Cela permet de voir un peu l'ambiance et la dynamique du développement du noyau. La partie 2 est vraiment un must, mais c'est peut-être un avis purement personnel. De toute façon comme le disent les autres le problème n'est pas d'en avoir trop, rien n'oblige à tout lire, mais plus le temps que cela te prends. Avec une table des matières en avoir trop devient juste absurde puisqu'on peut aller directement à la partie qui nous intéresse.

Personnellement okular me convient parfaitement sous Linux mais j'ai découvert il y a peu que le support PDFs des principaux lecteurs n'est pas aussi bon que celui d'Acrobat :

http://jean-christophe.dubacq.fr/post/Whydo-I-prefer-Acrobat(...)

Ceci dit il n'en reste pas moins que pour une utilisation bureautique normale (celle de M. tout le monde) ces alternatives sont suffisantes.

Cela fait un moment que je me dis que j'essaierai bien le dvorak et ce clavier avec plusieurs skins est très intéressant pour tester et passer d'un mapping à un autre. Néanmoins il ne semble pas posséder de rétro-éclairage.

Existe-t-il une solution équivalente avec rétro-éclairage ? Ou éventuellement un clavier dvorak bépo pur (pas de skin) rétro-éclairé ?

Du pur patrick_g comme d'habitude. Clair et complet.

Merci patrick_g

Globalement beaucoup de fonctions disparaissent en plus. Avec un clic droit on perd tout ce que le navigateur propose habituellement.

Concernant les éléments non textuels, ils peuvent être indéxés également si c'est du SVG qui est utilisé. Cela permet d'indexer le texte dans une image par exemple.

ça ressemble beaucoup à pubsub ce que tu décris. Il existe des contacts spéciaux à ajouter dans jabber pour avoir les flux RSS par jabber, ou même les mails il me semble. Il existe tout un tas d'applications qui utilisent jabber, comme des blogs qui indiquent ton état. Et si cela ne correspond pas exactement à ce que tu cherches à faire, tu peux toujours faire un patch ou même un rapport de bugs aux auteurs de ces logiciels.

A noter qu'il existe déjà une solution de ce genre fait par l'équipe REGAL du LIP6 : http://regal.lip6.fr/spip.php?rubrique18

Sans compter le problème du partitionnement. Actuellement c'est bien agréable de se dire que toute la conf tient sur une partition. Avec cette hiérarchie de fichier la conf est éparpillé dans toutes les applis. Bonjour l'intérêt ...

Bon peut-être que je ne suis pas difficile mais en tout cas je trouve les graphismes pas si mal du tout au contraire. Je m'attendais à quelque chose de beaucoup plus pixelisé et avec des champs à pertes de vue. A tester donc