lasher a écrit 2753 commentaires

Pour le coup c'est toi qui lis mal mes messages (ou bien je rédige très mal). La bêtise qualifiait smiley, qui justement voulait caractériser le côté « bête » de ma remarque. Bref, passons.

Je comprends parfaitement ce qu'est « une conditionnelle » comme tu le dis si elliptiquement bien. Maintenant, quand tu me cites mais que tu oublies la partie où je fais comprendre que j'ironise gentiment -- à la limite de la bêtise, c'est-à-dire quand tu coupes mon smiley, tu fais dire à ma phrase autre chose que ce que je voulais je pense.

Ensuite, je pense que tu peux au moins citer le cas de choses comme Mono, gnu classpath (au moins avant que Java ne soit vraiment libéré), les libc (qui ont des api -- voire des abi -- stables), etc.

En fait, dès qu'on parle « standard » (bon, ça, pas forcément) mais surtout de normes, il n'y a plus rien à dire, GPL, BSD, ou proprio, par définition, il faut pouvoir « interchanger » les appels de fonction (POSIX est l'exemple le plus criant, mais comme c'est un gros morceau de logiciel, je me permets de le recaser ici).

Je pense que ta question a déjà été posée lorsque les gens ont expliqué que faire un chroot ou un jail n'était pas non plus la panacée. Cloisonner peut aider à limiter les dégâts, mais pour le coup, je suis d'accord avec d'autres intervenants dans ce fil : un matériel/un service, ça reste dans l'absolu plus sécurisé. Maintenant, les notions de sécurité évoluent en fonction de la façon dont tu évalues les risques (sensibilité des données, etc).

Ah bon ? Donc les implémentations libres ou proprio des pthreads n'ont pas la même api (voire abi) ? :-)

De même qu'on voit mal des admins mettre en prod des debian testing, n'est-ce pas ? :-)

NIS+ ? LDAP + Kerberos + ... (l'équivalent d'active directory de Windows, quoi) ?

Va dire ça à Jaures.

Je fais bien la distinction GPL / LGPL, car la GPL seule est la plus restrictive.

Je ne connaissais pas Joomla. De plus, on peut difficilement taxer ZFS et DTRACE de « projets historiques ». :-)

Par contre, tu aurais pu parler de Java qui sera vraissemblablement en GPL v3, si j'ai bien compris.

Je me suis posé la question. Et en fait, en essayant un raisonnement logique, bien que contredisant mon intuition, je me suis dit que « c'est » était impersonnel, et qu'à aucun moment je n'employais la première personne du singulier. Cela étant, bien que « douloureux » à l'oreille, j'ai choisi « C'est moi qui a » (alors qu'à l'oral, sans me poser de question, j'aurais dit « c'est moi qui ai » .... comme quoi).

« J'ai toujours du mal à retenir un sourire quand on m'explique que les droits liés à la GPL sont trop restrictifs et donc que, en gros, 75% des logiciels libres restreignent les libertés ;-). »

Mmmh. Là c'est moi qui a souri. :-)

En pratique, certes, Linux est sous GPL, ainsi que les outils de ligne de commande de base (shells, etc). GCC aussi, et, dans une moindre mesure, emacs. Il y a évidemment pléthore de logiciels libres sous GPL -- et c'est très bien.

Maintenant, prenons d'autres logiciels libres qui sont aussi extrêmement utilisés.

- OpenSSH (BSD)
- Perl (Artistic license)
- Python (licence BSD-isante)
- Firefox / Thunderbird (MPL)
- Postfix (IBM Public License)
- Apache (APL)
- BIND (licence ISC)
- Sendmail (BSD jusqu'à la version 8.9 excluse puis, depuis quelques temps, une licence moins libre dans le cas d'un usage à caractère commercial sans redistribution des sources)
- X11 (MIT)
- ZFS
- DTRACE
- ...

Entre le nombre de softs sous GPL (indépendemment de la taille du projet), et la fréquence avec laquelle ils sont utilisés, il peut exister un gouffre énorme.

Évidemment, à mon énumération (non-exhaustive) de logiciels sous licence non-GPL, on peut opposer GIMP, Samba, etc.

Ce que je veux dire (et ensuite, j'arrête le troll pour 2h au moins), c'est que cette notion que « la licence GPL est la plus commune » est sans doute vraie en termes de quantité de logiciels publiés sur le net, mais pas nécessairement en termes de quantité de logiciels réellement utilisés par un nombre significatif de personnes.

Ce qui me fait dire que finalement, il n'y a pas tellement de quoi sourire quand on dit que la GPL est par trop restrictive -- en tout cas, pas en « brandissant » l'argument du nombre de softs sous GPL. :-)

« Ensuite, pourquoi 3 reseaux? --> Pour qu'il y ai une concurrence dans la qualité. »

Il ne faut quand même pas oublier que les trois opérateurs se sont pris une amende il y a peu parce qu'ils ont été reconnus coupable d'entente sur les prix (nuisant donc à la concurrence). Et même comme ça, je ne suis pas certain que ce ne soit pas encore le cas...

Ah.

Je connais au moins un domaine où la compilation peut prendre un temps pas possible : le calcul haute performance.

Un code scientifique, comportant de nombreuses indirections de tableaux (inévitables, car usant de maillages adaptatifs et de matrices creuses, qui intrinsèquement nécessitent ce genre de structures de données), avec pourtant le maximum de code dont le comportement est statiquement connu à la compilation (parce que programmé en FORTRAN 77 et donc pas de risque d'aliasing, etc), ça peut mettre dans les 45-60 minutes à compiler. Bon ok, le fait que le compilateur voie plein d'opportunités d'optimisation peut clairement jouer, mais la complexité du code est la principale raison de la lenteur de compilation.

Ici donc, pas d'objet, du bête code, à peine mieux que de l'assembleur (bon ok, j'exagère un chouilla).

Par contre, si on parle « presqu'objet », parlons des templates, qui de par leur côté totalement statique fait que les temps de compilation s'allongent, s'allongent ...

Enfin, là on parle de code C, et effectivement, gcc est clairement beaucoup plus lent qu'avant, alors qu'il a relativement peu de choses à analyser (comparé à du code C++).

C'est bien simple, d'après ce que je lisais, il n'y a tout simplement pas de main d'oeuvre dans OpenBSD (parce que pas de temps libre, trop de trucs plus urgents à faire) à consacrer à un compilateur quelconque. Donc non, pas de OpenCC ou autre.

Je ne sais pas ce que vaut pcc, mais tcc fait tout en une passe, et n'optimise pas grand chose (càd : rien). Ce n'est pas son but. Donc si pcc optimise des trucs, alors il est sans doute plus performant que tcc :-)

Oui enfin, poser des phi fonctions c'est pas dur non plus hein. Et si la représentation intermédiaire est bien faite, remonter les arcs c'est pas spécialement compliqué. Ce qui est difficile dans SSA, c'est le calcul des frontières de domination, etc. Donc tout dépend si l'algo est implémenté ou pas.

connasse : une grosse conne (notez qu'il n'y a pas d'équivalent masculin)

Mon Petit Robert 2006 me dit que "Connard, -arde, connasse, conne (conard -> conasse)", ça a du coup bien un masculin et un féminin...

Bon, j'ai vaguement essayé de ne rien dire concernant le troll BSD Vs GPL, de savoir à qui avait la plus grosse [1]. Mais, puisque tu te fiches de dire de la merde, je t'avoue que tes arguments, où tu dis que tu te fiches de savoir si ce que tu racontes est vrai, me semblent tout à coup bien moins intéressants à lire. Que tu sois exaspéré par les commentaires de certains, et que tu répondes en conséquence, admettons ; que, pour prouver que tu as raison, tu te permettes de mentir, c'est autrement plus gênant.


[1] liberté, évidemment.

« Certaines versions de BSD ne sont pas compatibles avec la GPL »

Tu es sûr de toi ? À ma connaissance, mis à part la clause de publicité (donner le nom des codeurs), je ne connais pas de licence BSD impliquant de garder le logiciel sous BSD.

« Bof les x86 (ainsi que d'autre proc) sont capable de reordonnancer les instructions. Or le volatile n'est utile que pour le compilo. Donc sans "memory barrier" y a des chances que ca marche pas. »

Euh, pas que pour le compilateur. Ça te garantit un comportement à l'exécution, et l'Out-of-Order n'y changera rien. Mais c'est vrai que si tu n'as pas de cohérence de cache, l'utilisation de volatile n'est pas bien intéressante.

« hum et tu fait comment pour modifier ton entier de maniere atomique (sans que plusieurs process quitte la boucle en meme temps) ? »

En fait je ne vois pas trop où est le problème de threads quittant la boucle en même temps, étant donné que c'est ce qu'on veut. Plus exactement : si j'ai X threads à synchroniser, et que chacun a un boulot prenant grosso-modo le même nombre de cycles, alors je peux tenter une attente active pour réduire au maximum le temps de synchro. Ensuite, je n'ai plus qu'à avoir un pseudo code du genre

volatile int n = NB_THREADS_TOTAL;
/* début du thread : « fork » */
/* boulot ... */
n--; /* s'effectue atomiquement, sans risque de cafouillage car c'est un volatile int (on suppose un mécanisme de cohérence de cache) */
while (n > 0);
/* join(), ou bien suite du boulot à faire pour le thread */

Évidemment, je ne donne que l'idée principale.

au sens OSI du terme ? :-)

Bof.

En pratique, quand les messieurs d'OpenBSD ont gueulé un grand coup contre tous ces profiteurs qui utilisaient OpenSSL/OpenSSH sans jamais rien reverser (argent ou matériel), certaines boites qui font leur beurre en partie avec ont fini par donner un petit quelque chose. Comme quoi, si le projet en vaut le coup, licence BSD ou pas, les boites veulent bien aider aussi (évidemment, il faut que ce soit dans leur intérêt).

ben en faisant un bête [1]

while(entier>0) ;

« entier » étant déclaré volatile int entier;

On peut se permettre ça car en pratique, tu n'aura pas d'état inconsistant d'un registre entier (tous les bits sont basculés en même temps). Par contre, ça a un inconvénient si tu t'es planté pour l'attente, notamment pour le multi-coeur : un coeur se retrouve à monopoliser le bus d'accès mémoire, et peut donc empêcher ses petits camarades de travailler (donc il ne faut pas se planter).

[1] en fait il faut raffiner un chouilla plus, mais c'est l'idée.

« ca s'apelle un spinlock; et tu gagne beaucoup plus a faire un test_and_set fait en asm qu'a te le faire a la mano ;) »

Sauf que le T&S ne fonctionne (à ma connaissance) pas pour un grand nombre de processeurs (problèmes liés à la cohérence de cache, etc.).

« Ce qui est arrivé à Con, est arrivé à d'autres et aussi dans le domaine des serveurs. Vmware a essuié un refus il y a peu. IBM a aussi pris un refus pour son modèle de thread. Etc. »

Je ne sais pas si tu as lu l'article original, mais CK dit que son scheduler, qui pourtant avait été critiqué, a ensuite été adopté comme modèle, et récrit from scratch par d'autres dévs du noyau (ceux qui justement critiquaient son approche). C'est ça qui l'a fait craquer, plus que le refus en lui-même : le côté « non, on veut pas de ton truc car on pense que le concept ne convient pas, mais finalement l'idée est bonne, on va le refaire à notre sauce ».

Tu parles d'IBM, mais leur modèle de threads était plus flexible et performant que celui actuellement utilisé. Sauf que bon, comme le scheduler codé par un pote du mec qui a fait les NPTL, ben... Ils se sont arrangés pour que ça colle bien l'un avec l'autre (rendant l'un dépendant de l'autre, en fait), ce qui a nécessairement désavantagé les threads d'IBM...