Antoine a écrit 5722 commentaires

peut-être parce que ça n'a aucun intérêt de connaitre le chiffre exact.

Ou peut-être parce qu'il est dérisoire. Je suis sûr que Mandriva est très loin des 15% (et même des 1% sûrement).

Il est implicite que tu forkes après avoir chargé le code. Certes, si tu forkes à vide et que le code n'est pas encore chargé, l'OS n'a aucun moyen de savoir...
(mais l'interpréteur peut aussi faire un mmap() du bytecode auquel cas l'OS est capable de partager les données)

He bien lance, n'importe quel langage interprété et regarde toi-même le résultat moi, je le connais, j'ai déja testé.

Je vois, c'est précis et circonstancié :)

la plupart des grosses boîtes travaille avec java (c'est la vie)

En même temps, c'est pas le sujet du journal (PHP / C++).

l'os va savoir que buf est du code et va appliquer le copy-on-write ?

Il s'en fout, banane.
Le COW est fait au niveau des pages de la mémoire virtuelle, le premier accès en écriture sur une page partagée est intercepté (tu sais, le noyau a le pouvoir de modifier les flags de lecture/écriture de chaque page ; non, ce n'est pas un truc de « bisounours ») afin de départager la page.

Va voir http://fr.wikipedia.org/wiki/Copy-On-Write

Lance 10 instances jboss avec struts pour un simple hello world, on en reparle après. Plus simple, lance 100 fois php sur le même code.

C'est un benchmark stupide. On ne compare pas l'efficacité de différents langages sur un hello world.

Ensuite, je répète : si ton truc est mal dimensionné au point de swapper, c'est ta faute et pas celle de PHP/Java/Python/C++. Point barre.

le code compilé réside intégralement dans le cache instruction

Le cache instruction fait 32 ou 64K selon les CPUs, tu auras du mal à me trouver une application moderne qui tient dans cet espace.

il ne faut pas longtemps pour comprendre que la surpression sur le cache L1 entraîne un surnombre de cycles inutiles rien que pour la gestion des données réelles du programme

Sauf que comme mentionné plus haut, le bytecode d'un langage interprété est plus compact que le code machine équivalent. Donc l'efficacité cache de ce bytecode est meilleure et non moins bonne.

T'es gentil, mais je ne fais pas de Java et je ne vais pas me farcir trois tonnes d'installations pour vérifier si ton argument tient la route :-)
De plus prendre Java comme modèle de ce que peuvent consommer PHP ou Python, ça tient du troll.

Par ailleurs il est reconnu que top est un très mauvais indicateur de la consommation mémoire. Tu peux essayer smem pour de meilleurs chiffres (mais bon, c'est un outil écrit en Python, j'espère que ça ne te dérangera pas trop :-)).
http://www.selenic.com/smem/

Mais pour l'OS du code source php, du byte code java, du parrot, ou tout autre truc interprèté ce n'est pas du code c'est du data.

Ça ne change rien. L'OS fait du COW aussi pour les segments data.

Du reste, un des avantages du bytecode des langages interprétés c'est que c'est en général beaucoup plus compact que le code machine équivalent (car les opérations représentées sont plus haut niveau). Donc je ne crois pas que ton argument tienne.

Mais pendant ce temps la mémoire est full et provoque du swaping

Heu, faut pas pousser mémé dans les orties. S'il y a du swapping ton machin est mal dimensionné, c'est tout (et il s'écroulera dès qu'il y a une montée en charge).

Et _ça_ c'est clairement pas efficace sur le plan énergétique.

Heu, ben, il faudrait quantifier un minimum.
Un CPU serveur c'est grosso modo entre 10 W (au repos) et 100 W (en charge) de consommation.
Une barrette de RAM (disons 2 ou 4 Go), c'est combien?

Réduire la consommation mémoire permet avec nos super CPU multi-cores de faire tourner des tonnes de process

Evidemment, ça dépend du tonnage de la tonne ;-)
Mais bon, si tu mets trop de processus sur un CPU unique, tu prends le risque d'une montée en charge simultanée des différents processus qui va écrouler ton joli serveur.

Après, des chiffres concrets sont les bienvenus ;)

Si je me souviens bien, la RAM dynamique (DRAM, celle des barettes alors que le cache du CPU est en général de la RAM statique -- SRAM) a juste besoin d'être rafraîchie une fois de temps en temps en réécrivant le contenu des cellules à l'identique.
Bon mais je ne suis pas spécialiste.

La différence vient de la consommation de mémoire.

Ça m'étonne beaucoup ça. Une barrette de RAM consomme une fraction de ce que consomme un CPU. D'ailleurs si tu regardes bien à l'intérieur de ton PC, le CPU a un gros dissipateur bien lourd avec un ventilateur posé dessus, tandis que la RAM n'a strictement rien sur elle ;-)

le code n'est pas considéré comme du code par l'os mais des données => tu lances 2 fois la même applic et pouf pas de segments partagés

C'est faux ça. Les OS modernes (Linux) font du COW (copy-on-write) lorsqu'on forke un processus, du coup les données qui ne changent pas sont partagées de facto.

(évidemment si tu lances des processus individuels au lieu de forker, ce sera pas la même chose ; mais est-ce un cas courant ? d'autant qu'on parle d'applis Web ici)

on se rend vite compte que les processes restent un certain temps en mémoire mais ne foutent rien.

Et alors ? Qu'elle soit vide ou pleine, la mémoire va consommer la même énergie. Ce qui modifie la consommation de la mémoire, ce sont les accès. Mais si comme tu le postules les processus "ne foutent rien" alors il n'y aura pas d'accès à la mémoire de ces processus.

n'est-ce pas Nicolas Sarkozy qui a déclaré à ce propos "Car le prix le plus bas n'est pas forcément le meilleur"

J'ai entendu dire que l'entrée de gamme Rolex était de très mauvaise qualité.

Par contre si un fichier dans ta distribution est en GPLv2+, ils peuvent bien sûr le reprendre de ta distribution et l'utiliser/distribuer en v2+...

C'est bien ce que je dis.

mais si tu as patché le fichier avec du code v2 only (et marqué comme tel dans le fichier) ils ne pourront pas le faire tel quel, ils devront d'abord retirer le v2 only avant de pouvoir distribuer ce fichier en v2+

Tout à fait.

mais si tu distribues tout le projet en v2 only et que de plus en plus de patches sont en v2 only ben ça devient de plus en plus difficile de pouvoir extraire ce qui est en v2+ pour le réutiliser dans du v2+

Tout à fait (bis).

à part le fichier readme/licence qui indiquerait v2only

Ah ben c'est là qu'on n'est pas d'accord. Tu n'as pas le droit de modifier la licence d'un truc dont tu n'es pas l'auteur. Même la licence BSD interdit de modifier la mention de copyright et donc de licence (lis bien).

La grosse incompréhension ici c'est que tu penses qu'on a le droit de changer la licence du code concerné. Non, on ne fait qu'adjoindre des bouts écrits sous d'autres licences.

Alors maintenant je ne sais pas comment ca marche dans le cas d'un logiciel,

Oui c'est un peu la question. Que Perens bénéficie d'un droit moral sur son oeuvre, ça ne fait aucun doute (enfin, dans un pays reconnaissant le droit moral, par exemple la France). Que ce droit moral s'étende automatiquement aux modules écrits par d'autres auteurs, c'est plus douteux et je n'en sais strictement rien :-) Il y a des chances qu'il n'y ait aucune jurisprudence sur le sujet.

Note que le droit moral concernant le logiciel est très réduit, je crois qu'il ne contient que le droit de paternité (respect du nom de l'auteur). Le droit de divulgation et le droit de retrait ne sont pas inclus.

Le passage cité autorise explicitement de changer la licence lorsque l'on redistribue le code.

NON ! Il t'autorise à choisir la licence qui t'arrange pour déterminer TES droits, pas à changer la licence pour les autres utilisateurs à qui tu donnes des copies.
Après, si tu fais une oeuvre dérivée, tu peux mettre tes ajouts sous une autre licence, par exemple "GPL v2 only", ce qui fait que le tout ne pourra être utilisé que sous la GPL v2, mais les bouts de code originaux doivent rester sous la ou les licences originales.

et vu comme ça juridiquement rien n’empêche de supprimer une référence à une des licences, de ne garder que celle qui nous intéresse, et de le redistribuer comme ceci.

Non tu n'as pas le droit de supprimer une des licences :)
Si tu fabriques une oeuvre dérivée, tu peux licencier cette oeuvre dérivée (dans son ensemble) sous une de des deux licences si ça te chante, mais tu n'as pas le droit de changer les termes de licence des bouts de code qui ne sont pas de toi.
Même la licence BSD, tu n'as pas le droit de la supprimer.

C'est à dire pas grand chose.

Heu... pas dans le cas discuté. Ici, la proportion de code restant de Bruce Perens dans BusyBox semble de l'ordre du pouillème.

disons que pour pouvoir opérer un changement de licence désiré par la nouvelle équipe, celle-ci a procédé à une épuration des sources en virant ou remplaçant tout ce qui restait sous (c) de Bruce Perens.

Ceci très bizarrement alors que ce n'était pas nécessaire. Il suffisait de laisser les bouts de code de Bruce Perens sous "GPL v2 or later" et de passer l'ensemble sous GPL v2 tout court.

Il y a donc probablement une belle part d'animosité, et/ou d'incompétence (les deux faisant souvent fort bon ménage).

Non car il est conditionné à l'existence de l'en-tête spécial "X-Gendarmerie" (*).


(*) qbag yr pbagrah rfg puvsseé nirp ha EBG13 vaivbynoyr

Je ne sais pas comment ca se passe aux US, ni sur les logiciels. Mais en ce qui concerne le droit d'auteur classique, la paternité EST l'apanage de l'auteur initial.

Ben non. Dans ton exemple, l'auteur de l'oeuvre initiale comme l'auteur de l'oeuvre dérivée ont tous les deux un droit moral (évidemment, le second auteur n'a un droit moral que sur l'oeuvre dérivée). S'il est interdit de ne pas respecter la paternité de l'auteur initial, il est également interdit de ne pas respecter la paternité de l'auteur subséquent.

J'ai rapporté un bug chez Mandriva : https://qa.mandriva.com/show_bug.cgi?id=56374

Je ne vais pas m'amuser à recompiler Firefox (pas fou), par contre sur mon netbook je crois que je vais installer un build officiel de la 3.5 voire de la 3.7.

Pas besoin d'être sorti de la cuisine à Jupiter

Miam miam, ça doit être bon là-dedans.

Oui c'est ce qu'il ressort de http://busybox.net/~landley/forensics.txt :

“Despite this, in September 2006 Bruce posted a series of increasingly confrontational mesages to the BusyBox mailing list objecting to the the plans of the current maintainer (me) to release new versions of BusyBox under GPL version 2 (rather than GPLv2 or later).”

Il serait intéressant de savoir pourquoi ils refusent la GPLv3 au point de changer le copyright officiel.

Créateur, ça ne veut rien dire sauf en langage religieux. En matière juridique, il n'y a que des auteurs, et celui qui initie l'oeuvre n'a pas de statut spécial (ce qui se comprend d'ailleurs... mettons qu'un petit exemple de 50 lignes soit initialement repris par quelqu'un pour construire un logiciel qui finit par faire des millions de lignes, pourquoi l'auteur des 50 lignes originales serait-il important ?).

Certes, il y a paternité, mais la paternité est partagée entre tous les contributeurs. Elle n'est pas l'apanage de l'auteur initial.

Notons aussi que sous linux, on a les problemes de fsync (notament via sqlite)

Sauf erreur de ma part, c'est désactivable (cf. « PRAGMA synchronous »).

Un problème avec Mozilla c'est que les builds officiels ne sont pas intégrés au bureau, que ce soient les icones, le rendu des fontes (atroce), etc. Du coup on peut bien tester 5 minutes pour voir, mais on retourne vite fait au client fourni par la distro.