gouttegd a écrit 1805 commentaires

Tiens, je n’ai aucun clignotement sous Uzbl, on dirait que Webkit ne supporte pas la balise blink… auquel cas je dirais volontier “It’s not a bug, it’s a feature!”

Il ne te reste plus qu’à changer de navigateur jusqu’à demain. :)

Je n'ai pas encore regardé de très près le code, mais une chose me pose un petit soucis, c'est l'API.
En effet, le seul moyen de profiter de ce code, c'est de passer par une fonction bloquante, qui oblige à utiliser des threads si le programme qui l'utilise, doit pouvoir faire autre chose pendant ce temps.

Je n’ai effectivement pas réellement écrit la fonction wait4all en ayant à l’esprit qu’elle devrait être ré-utilisable dans n’importe quel contexte. Elle est faite pour répondre aux besoins de ce programme, pas plus.

En faire une sorte de bibliothèque générique de monitoring de processus n’était pas du tout mon objectif. Je n’ai rien contre l’idée (si le besoin existe, pourquoi pas ?), mais franchement je ne pense pas vouloir m’y atteler.

Peut-être qu’améliorer la bibliothèque libkqueue (en y apportant le support de Netlink) serait une meilleure idée ?

En tout cas, merci beaucoup d'avoir partagé.

De rien, merci pour le retour.

N’est-ce pas déjà ce que fait distccd(1) ?

C’est prévu pour compiler à travers le réseau, mais qui peut le plus peut le moins, donc si on peut envoyer les fichiers à compiler à des démons sur d’autres machines, on doit aussi pouvoir les envoyer à un démon distccd sur la machine locale.

(Enfin je suppose, je n’ai jamais utilisé distcc.)

Pour info, je viens de mettre à jour le dépôt.

J’ai ajouté un filtre LSF (Linux Socket Filter, la version linuxienne de BPF) pour ne recevoir que les messages concernant les processus à attendre, et limiter ainsi le risque de ENOBUF.

J’ai aussi ajouté le support de kevent(2) pour les systèmes BSD, du moins sur le papier parce que je ne peux pas tester si ça fonctionne correctement ni même si déjà ça compile (je n’ai pas de machine, même virtuelle, sous BSD et je n’ai pas la motivation d’en installer une juste pour ça)… Ça devrait marcher si j’ai bien compris le manuel, mais si un utilisateur de BSD est intéressé pour tester, je suis intéressé par les retours.

la version avec polling a une race, si jamais le PID est recyclé entre deux polling.

Oui, j’avais conscience de ça, mais je n’ai pas spécialement cherché à l’éviter pour l’instant.

Je garde ton approche basée sur /proc/pid/status dans un coin, mais je dois admettre qu’étant sous GNU/Linux moi-même et disposant donc de Netlink, la méthode avec polling n’est vraiment qu’une solution de repli,¹ que je ne suis pas réellement motivé à améliorer…

Pour les systèmes autres que Linux, je serais plutôt enclin à regarder du côté des mécanismes équivalents à Netlink, s’il en existe. Par exemple, je viens de voir que FreeBSD a un appel kevent qui devrait permettre de faire sensiblement la même chose, je vais regarder ça de plus près.

le socket netlink reçoit un message par fork()/exec()/exit(), pour tous les process sur la machine: s'il beaucoup de process sont créés, le socket buffer risque de se remplir.
[…]
Tu devrais pouvoir mettre en place un filtre pour ne recevoir que les notifications d'intérêt, c'est pas trivial (BPF) mais ça peut être intéressant ;-)

Je vais regarder ça, merci pour l’info.

---

¹ En fait, la principale raison d’être de la méthode de repli en cas d’absence de Netlink est de m’éviter de passer pour un développeur linux-centrique (ce qui est perdu d’avance, puisque je suis linux-centrique — mais je me soigne).

Merci pour les remarques et le patch.

Il y a un problème dans le cas où netlink n'est pas supporté et on passe le PID d'un process auquel on ne peut pas envoyer de signal: EPERM est retourné par kill(), et wait4 ne va jamais retourner.

C’est le comportement voulu : si kill(2) renvoie EPERM, c’est que le processus cible existe (on ne peut pas lui envoyer de signal, mais peu importe, savoir que le processus existe est la seule chose qui nous intéresse), et qu’il faut donc continuer à l’attendre. Ce n’est que lorsque le processus n’existe pas ou plus (soit lorsque kill(2) échoue avec errno == ESRCH) que l’on peut retourner.

Je note les remarques concernant le gestionnaire de signal.

Sinon :

ec = payload->evt.event_data.exit.exit_code / 256;

Tu peux utiliser WEXITSTATUS().

Ah, merci ! Ça me dérangeait de devoir utiliser une constante magique.

Je ne crois pas, non. La GPL oblige à fournir les sources seulement au destinataire du programme. Si B distribue le logiciel à C, B est tenu de fournir les sources (y compris ses éventuelles modifications) uniquement à C ; A n’est pas impliqué et ne peut rien réclamer (enfin, il peut, mais rien n’oblige B à accéder à sa demande).

(Disclaimer : j’ai déjà par le passé commis quelques grosses erreurs d’interprétation des licences GNU, je ne suis pas à l’abri de recommencer.)

Si tu considères le libre comme une religion ou il faut immoler tous ceux qui ne pensent pas comme RMS, oui, alors certes…
[…]
Aux yeux de la FSF, mon éthique n'est pas celle de RMS et je ne suis pas un mouton.

Ce que tu sembles ignorer, c’est que RMS et la FSF ne sont pas les seuls à dire que l’interdiction de l’usage commercial va à l’encontre du libre. C’est un point commun à toutes les définitions usuelles du libre, celles qui sont acceptées par tout le monde (la FSF, l’OSI, Debian, les projets BSD, etc.).

Merde, c’est même un des principaux points sur lesquels des personnalités aussi opposées que Stallman, Torvalds ou De Raadt sont complètement d’accord.

Oh bon sang, j’ai bien mis une bonne minute à comprendre, mais ça m’a bien fait rire ! :D

Malheureusement, non, Poettering n’a rien à voir là-dedans.

Les Alliés n'étant pas en reste:

• la plupart des villes allemandes rasées (suivant la technique du «carpet bombing»)
• bombes atomiques sur Hiroshima et Nagasaki.

Il n’y a pas eu que Hiroshima et Nagasaki… la plupart des grandes villes japonaises ont été la cible de bombardements conventionnels entre juin 1944 et août 1945. Il y eut notamment une série de raids incendiaires particulièrement destructeurs en mars 1945, dont certains auraient fait plus de morts que les bombardements nucléaires des 6 et 9 août.

(Désolé pour la digression, mais j’ai toujours trouvé quelque peu choquant qu’on ne se souvienne que de Hiroshima et Nagasaki, comme si ces deux bombardements éclipsaient tous les autres.)

Pour info, au cas où ce soit pertinent ce même ordi possède une deuxième distrib (mageia 2) avec le noyau 3.4.24 et je n'ai jamais eu de problèmes de ce genre.
Maintenant il y a peut-être des options du noyau qui n'ont pas été sélectionnée??

C’est possible. Si tu veux essayer de comparer la configuration des noyaux, elle est normalement exportée au format texte (compressé) dans /proc/config.gz.

Comparer la liste des modules chargés dans chaque distribution (avec lsmod) peut aussi être intéressant.

J’ai eu à une époque semble-t-il le même problème que celui que tu décris, ou un problème présentant les mêmes symptômes : impossible de mettre en veille deux fois d’affilée.

Le problème a disparu après une mise à jour du noyau. Malheureusement, je serais bien incapable de dire aujourd’hui quelle était la dernière version du noyau à souffrir de ce problème…

Je recommanderais de tester le dernier noyau en date.

Windows XP nécessite au minimum 256Mo de ram

Euh, je faisais tourner Windows XP avec 32 Mo de RAM… J’ai utilisé ça pendant près d’un an, ce n’était peut-être pas super confortable mais ça marchait bien.

Pour ce qui est de l’espace disque, le même Windows XP fraîchement installé prenait précisément 2,3 Go — je m’en souviens très bien, vu qu’avec un disque de 6 Go, à l’époque j’étais très regardant sur l’espace disque occupé par n’importe quel logiciel, y compris l’OS).

En résumé, il s'agit d'un ajout afin que toute modification, voire fourchette, soit obligatoirement re-distribuée sous un autre nom que le nom original. Et ça, ça me semble intéressant et pertinent. C'est même étonnant qu'un équivalent n'existe pas déjà.

Ça existe, dans la LaTeX Project Public License, sous une forme légèrement différente selon la version :

Version 1.2 :

You may distribute a modified file of The Program if, and only if, the following eight conditions are met:
[…]
3. You must not distribute the modified file with the filename of the original file.
[…]
5. You must change any identification string in the file to indicate clearly that the modified file is not part of The Program.

La version 1.3c est un peu moins exigeante au prix d’une formulation plus lourde :

[…] you may distribute a Derived Work provided the following conditions are met […]
a. If a component of this Derived Work can be a direct replacement for a component of the Work when that component is used with the Base Interpreter, then, wherever this component of the Work identifies itself to the user when used interactively with that Base Interpreter, the replacement component of this Derived Work clearly and unambiguously identifies itself as a modified version of this component to the user when used interactively with that Base Interpreter.

Je trouve intéressant de voir ce qu’en dit la FSF, pour laquelle la LPPL 1.2 est bien une licence libre, mais :

This license contains complex and annoying restrictions on how to publish a modified version, including one requirement that falls just barely on the good side of the line of what is acceptable: that any modified file must have a new name.

… et sur le site du projet GNU, en plus !

Même si ton application est développée pour un seul navigateur, elle est multi-plateformes.

Dans l’exemple 1 ci-dessus, je consulte le site avec Firefox sur GNU/Linux, combinaison qui n’est pas supportée (seul « Mozilla Firefox sur “Windows PC” » l’est)…

Les applications web qui t'affichent ces messages ne devraient pas les afficher, mais mieux gérer leur développement pour être multi-navigateurs.

C’est bien là mon point. Il faut explicitement coder le support pour les différents navigateurs pour que ça marche (exactement comme un programme natif). Si les technologies web étaient à la hauteur de leurs promesses, il ne devrait pas en être ainsi.

Le « write once, run on every navigator » n’existe pas.

C'est juste multiplateformes, normalisé (plus ou moins mais c'est le boulot du w3c), non lié à une implémentation,

Que les applications web commencent déjà par être multi-navigateurs avant de vouloir être multi-plateformes.

Exemple 1 :

Warning: your Plateform is not fully supported by our web site!
Please use Internet Explorer version 5.5 or higher, or Mozilla Firefox on "Windows PC".
If you run Mac OSX on Mac, please use Safari.

Exemple 2 :

Sorry, your browser is unsupported so NCBI web applications may not function properly.

Si le développeur d’une application web doit explicitement supporter les différents navigateurs, en quoi est-ce différent d’un développeur d’applications natives qui supporte plusieurs systèmes à coups d’ifdef ou assimilés ?

le libre est toujours open-source, mais pas réciproquement.

Ça dépend de quoi on parle. Si on parle d’un logiciel, alors si, c’est parfaitement équivalent.

Un logiciel libre garantit à son utilisateur les fameuses « quatre libertés » ; un logiciel open source satisfait les dix critères de l’Open Source Definition. Or les quatre libertés (telles qu’exprimées par la FSF) et les dix critères de l’OSD se recoupent largement, c’est juste que l’OSD est un peu plus verbeuse et prend davantage de précautions. Par exemple, l’OSD comprend deux critères spécifiques pour interdire explicitement la discrimination à l’encontre de certains utilisateurs et de certains usages, là où pour la définition de la FSF cette non-discrimination est implicitement contenue dans la « liberté 0 » (liberté d’utiliser le programme — sous-entendu, indépendamment de qui est le destinataire du programme et de ce qu’il veut en faire).

La différence entre « libre » et « open source » ne concerne que les personnes qui développent les logiciels, pas les logiciels eux-mêmes, et réside dans leurs motivations. Il y a de multiples raisons qui peuvent pousser un développeur à publier son code sous une licence libre (= open source), mais schématiquement on les classe en deux grandes tendances : les raisons idéologiques (par exemple, « parce que le proprio c’est mal »), c’est la tendance « logiciel libre », et les raisons pragmatiques (par exemple, « parce que le code libre est techniquement supérieur »), c’est la tendance « open source ».

Mais quelles que soient les motivations des développeurs, le résultat est le même : le code publié est libre.

Oui enfin si tu n’aimes pas le webmail qu’on t’impose, installer un client lourd me semble quand même une façon beaucoup plus simple de passer outre que d’installer un serveur intermédiaire avec le webmail que tu veux… Si tu sais configurer un webmail pour « taper en IMAPS sur le serveur adéquat », tu devrais pouvoir configurer Thunderbird, Claws-Mail, Evolution, Outlook (ou même, soyons fous, Mutt) pour faire la même chose, non ?

je veux bien qu’on puisse préférer les webmails, mais au point de préférer se taper l’installation de son propre webmail plutôt que d’un simple client lourd…

Dans le même ordre d’idée, systemd ne semble pas pouvoir remplacer complètement cron, la syntaxe des « timer units » n’étant pas aussi expressive qu’une crontab :

Timer units currently have no support for calendar times (i.e. cannot be used to spawn things "at 6 am every Monday", but can do "run this every 7 days"), but for the usual /etc/cron.daily/, /etc/cron.weekly/, … should be good enough, if the time of day of the execution doesn't matter (just add four small service and timer units for supporting these dirs. Eventually we might support these out of the box, but until then, just write your own scriplets for this).

— systemd Optimizations

Ya pas plus horrible que cron, plutôt, si il n'est pas accompagné d'une interface utilisateur

Alors qu’avec systemd, bien sûr, ce ne sera pas nécessaire, tout le monde pourra écrire des « timer units » sans jamais consulter la documentation…

Qu’est-ce que systemd va changer ? Avec cron, les « barbus » éditent leur crontab avec leur vi et leur couteau tandis que les utilisateurs normaux utilisent un « planificateur de tâche » graphique comme ceux fournis avec Gnome ou KDE. C’est dépassé et horrible.

Avec Systemd, les « barbus » éditeront les fichiers « unit » de systemd avec leur vi et leur couteau tandis que les utilisateurs normaux passeront par un « planificateur de tâche » graphique. Ce sera moderne et user-friendly.

Pour information, c’est déjà présent dans la version actuelle (3.6), mais « caché » dans les experimental features parce que pas encore suffisamment stable.

La solution, c'est de prendre son courage à deux mains et d'utiliser un format prévu pour la gestion de version.

Tu as probablement raté ce passage de la discussion :

Comme je l'ai précisé je travaille en inter-entreprise, je ne suis pas du tout en position de changer le format de fichier utilisé.

Ce n’est donc pas une question de courage, sauf si tu proposes à l’auteur de pousser une bonne gueulante pour tenter de convaincre ses interlocuteurs — auquel cas à mon avis ce n’est pas de courage qu’il aura besoin, mais d’une promesse d’embauche dans une autre boîte…

Par ailleurs :

Dans les boites où j'ai été, j'ai toujours vu:

les développeurs faire du html ou un format wiki.
les rédacteurs techniques faire du docbook ou dita.
les chercheurs faire du latex.
les commerciaux et les manageurs utiliser un traitement de texte.

Petite devinette: qui produit des documents immondes, passe son temps à fusionner ligne à ligne et se plaint de perdre des versions?

Tous ceux qui ne savent pas utiliser leurs logiciels, quels qu’ils soient.

Encore une fois, il est tout-à-fait possible de travailler efficacement avec un traitement de texte (que ce soit MSO Word ou LO Writer). La séparation du fond de la forme, la génération de documents esthétiquement corrects, la possibilité de gérer différentes versions et de suivre les modifications ne sont pas l’apanage des solutions à base de LaTeX, DocBook ou autres markdown ou assimilés.

La différence est que les utilisateurs de LaTeX/DocBook/etc. ont nécessairement appris à se servir de leurs outils (parce que ces outils sont inutilisables sans un minimum (?) d’apprentissage), alors que la plupart des utilisateurs de traitement de texte pensent que ce n’est pas la peine.

Tant que ces utilisateurs ne comprendront pas que pour être efficaces ils doivent apprendre à utiliser leur logiciel (même s’il semble très intuitif) au même titre qu’un ouvrier doit apprendre à utiliser sa machine, toute solution technique est vouée à l’échec.

J'ai jamais testé la gestion de version dans une suite office, aucune idée de la qualité du truc.

Ce n’est pas mal du tout et ça peut rendre de fiers services, à condition que tous les utilisateurs jouent le jeu et fassent l’effort de s’en servir correctement — ce qui, dans mon expérience, n’a jamais été le cas…

C’est en fait le même problème dont souffrent les outils comme Alfresco ou SharePoint, ainsi que le relève l’auteur du journal : ces solutions sont efficaces, mais

seulement si les gens ont pris le temps d'apprendre à utiliser le logiciel, ce qui est rarement le cas.

C’est un peu comme les styles : les styles sont un excellent outil qui, bien utilisés (ou même, simplement, utilisés tout court), permettent de structurer un document et d’en séparer le fond de la forme (non, il n’y a pas que LaTeX qui permet ça). Mais la plupart des utilisateurs ne savent même pas que ça existe et ceux qui le savent n’en voient pas l’intérêt…¹

---

¹ Observations de l’Institut National de Pifométrie réalisées, d’une part, sur un échantillon représentatif (ou pas) de 107 étudiants entre septembre et octobre 2010, et d’autre part, sur un échantillon encore moins représentatif d’une dizaine de proches collaborateurs entre 2007 et 2012.

Mais si tu t'amuses avec ton SMTP de chez toi alors que free a une entrée SPF, j'avoue que je n'aurai aucun remord à te mettre en "SMTP sans doute de spammeur"

En l’occurence, il semble que free.fr n’a pas d’entrée SPF (ni de SenderID), donc le fait qu’un mail de free.fr ne vienne pas des serveurs de free.fr ne peut pas motiver une « présomption de spam ».