Ada est un excellent langage, mais ne rend pas les programmeurs plus intelligents ... Ce qui mène à des explosions de fusée à cause de programmeurs qui font des hypothèses erronées quant à la taille de certaines variables.
Il ne faut pas confondre « null » (la « valeur ») et « NullPointerException » qui est une exception, comme son nom l'indique. Mon prof de typage dirait que dans ce dernier cas, on se retrouve bien dans une situation clairement définie, et définitivement non « bloquée » : on sait où a eu lieu l'exception (la jvm a même la politesse de nous donner la ligne pour le source), et on n'a pas de risque de comportement indéfini (comme par exemple lorsque j'écrase la pile d'un thread avec un autre de mes threads en C...).
Java embarque une plâtrée de lambda calcul dans son moteur, justement pour assurer une certaine sûreté des types. Le seul moment où ce n'est pas vrai, c'est avec les types de base (int, char, byte, etc.), où là par contre, on peut encore faire du cast sauvage (jusqu'à certaines limites).
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).
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...
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.
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.
« 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 */
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).
[^] # Re: …da sur mon bidet
Posté par lasher . En réponse au journal Qu'est-ce qu'un langage sécurisé ?. Évalué à 8.
Ada est un excellent langage, mais ne rend pas les programmeurs plus intelligents ... Ce qui mène à des explosions de fusée à cause de programmeurs qui font des hypothèses erronées quant à la taille de certaines variables.
[^] # Re: Il y a deux notions de langage securise
Posté par lasher . En réponse au journal Qu'est-ce qu'un langage sécurisé ?. Évalué à 1.
Java embarque une plâtrée de lambda calcul dans son moteur, justement pour assurer une certaine sûreté des types. Le seul moment où ce n'est pas vrai, c'est avec les types de base (int, char, byte, etc.), où là par contre, on peut encore faire du cast sauvage (jusqu'à certaines limites).
# "coquille"
Posté par lasher . En réponse à la dépêche Le Cray XT-5 entièrement sous Linux. Évalué à 3.
[^] # Re: Architectures supportées
Posté par lasher . En réponse à la dépêche Sortie d'OpenBSD 4.2. Évalué à 1.
[^] # Re: Architectures supportées
Posté par lasher . En réponse à la dépêche Sortie d'OpenBSD 4.2. Évalué à 0.
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).
[^] # Re: Xen²
Posté par lasher . En réponse à la dépêche Sortie d'OpenBSD 4.2. Évalué à 2.
[^] # Re: Architectures supportées
Posté par lasher . En réponse à la dépêche Sortie d'OpenBSD 4.2. Évalué à 2.
[^] # Re: Linux
Posté par lasher . En réponse au journal FreeBSD 7.0 arrive...et il a les crocs !. Évalué à 4.
[^] # Re: Je pige pas trop...
Posté par lasher . En réponse au journal Bientot l'interdiction des cartes graphiques puissantes?. Évalué à 1.
[^] # Re: Et alors?
Posté par lasher . En réponse au journal A quand un Ministère de la Vérité. Évalué à 0.
[^] # Re: Pourquoi GPL ?
Posté par lasher . En réponse à la dépêche Alfresco relâche JLAN en version 4.0. Évalué à 1.
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.
[^] # Re: Pourquoi GPL ?
Posté par lasher . En réponse à la dépêche Alfresco relâche JLAN en version 4.0. Évalué à 1.
[^] # Re: Pourquoi GPL ?
Posté par lasher . En réponse à la dépêche Alfresco relâche JLAN en version 4.0. Évalué à 4.
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. :-)
[^] # Re: A quoi ca sert ?
Posté par lasher . En réponse au journal Pas de licence 3G pour Free.. Évalué à 3.
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...
[^] # Re: Re:
Posté par lasher . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 3.
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++).
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par lasher . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 1.
[^] # Re: Fin de gcc dans les *BSD
Posté par lasher . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 1.
[^] # Re: llvm
Posté par lasher . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 2.
[^] # Re: -asse = affectif
Posté par lasher . En réponse au journal Qui traite du D de Digitalmars, et dans une moindre mesure du français chez les jeunes, ainsi que du vote des personnes ayant double nationalité. Évalué à 3.
Mon Petit Robert 2006 me dit que "Connard, -arde, connasse, conne (conard -> conasse)", ça a du coup bien un masculin et un féminin...
[^] # Re: Alors ca c'est du bon
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 4.
[1] liberté, évidemment.
[^] # Re: Alors ca c'est du bon
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 0.
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.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
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.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
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
Évidemment, je ne donne que l'idée principale.
[^] # Re: Et Novell?
Posté par lasher . En réponse au journal Microsoft vous aime.. Évalué à 4.
[^] # Re: Et alors ?
Posté par lasher . En réponse au journal Microsoft vous aime.. Évalué à 7.
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).