reno a écrit 3886 commentaires

Je croyais que c'était une implémentation de Smalltalk et que c'était un ensemble de librairies..
Quelles sont les différences entre les langages?

C'est un troll ou tu le pense sincèrement?

Parce que pour moi, l'appel de méthode par introspection c'est un peu l'ultime recours: ça marche mais tu viens de jeter a la poubelle toutes les aides qu'apportent le typage statique, donc ton code devient beaucoup plus difficile a maintenir..

On n'en lit que du bien

Ah? Retire les œillères alors, parce que j'ai lu quelques critiques de gens qui ont des problèmes..

Et l'attitude du gars qui fait le module de configuration est bien dans l'esprit KDE: avant il y avait une case pour désactiver la fonctionnalité mais de toute manière c'est inutile de désactiver car maintenant ça marche et si on rajoute son home a la liste des répertoires a ignorer ça désactive la fonctionnalité donc j'ai supprimé la case.

Super intuitif, comme méthode de désactivation! Merci!

Il me semble que rien n'est prévu dans le protocole pour que le client sache si le serveur dessine les décoration. Donc, il y a un grand risque que le client et le serveur dessine les décoration, ce qui serait très moche.

Dans les discussions ce serait fait dans le protocole "xdg-shell", mais ça n'est pas implémenté effectivement.

Ce choix technique me semble très douteux. Peut être que Wayland ne sera pas une si bonne chose finalement?

Attention de ne pas accuser le mauvais responsable! Le protocole Wayland supporte la gestion de décoration coté client ET/OU coté serveur (la preuve: KWin a prévu de faire ça sur Wayland).

Après les devs Wayland sont en général pour la gestion de la décoration coté client car "c'est plus joli" (pixel perfect) et ont implémenté ça dans Weston, mais bon ce n'est pas une raison pour leur faire porter le chapeau: si un toolkit ou une app ne supporte que la gestion des déco coté client sur Wayland c'est de la faute des dev du toolkit ou de l'app, pas de Wayland..

De la même manière bien des problème d'X11 viennent en fait des toolkit: un exemple les toolkits ont beaucoup trainé pour passer à XCB à la place d'XLib..
```

Oui, enfin la dernière fois que j'ai entendu parler de Linux/x32 c'était car il y avait une grosse faille qui était restée ignorée car personne n'utilisait x32, alors bon..

Dans le cas d'openssl il y a eu des analyses, mais elles ont loupes ce bug, cf http://blog.regehr.org/.
L'analyse ne fait pas tout, après il faut distinguer les faux positif des vrais bugs, corriger le bug sans en introduire un nouveau (Debian..)

Je trouve que le titre de son message est mal choisi car il ne flingue pas que OpenSSL: il y a les CAs aussi dans le lot..
Ce qui est amusant, c'est que ça fait pas mal de temps que je lis que nos mécanismes de sécurité sont ridicules, mais on ne se réveille qu'avec Heartbleed mais bon je ne suis pas optimiste: l'attention semble se focaliser sur l'implémentation alors que n'importe quel CA peut te trahir..

car n'importe qui qui a déja utilisé la shm sait à quel point c'est pénible, contraignant et source d'erreurs ( deadlock entre autre ).

Facepalm, mais tu le fait exprès ou quoi?
Avec les threads en C toute tes variables globales sont en mémoire partagée (pas en D ou par défaut toute variable globale est en TLS ce qui est un bon changement) donc la source d'erreur des deadlock, ELLE EST OMNIPRESENTE AVEC LES THREADS!!
Mais pas avec les processus ou tu utilise la mémoire partagée uniquement aux endroits où tu en as besoin pour des raisons de performances..

J'ignore si tu trolle ou si c'est par pure ignorance, mais les processus étant plus sûr que les threads (pas d'état global partagé par défaut), pour privilégier la fiabilité, on devrait utiliser les processus par défauts sans shm, puis s'il y a un problème de perf les processus avec shm et seulement les threads si il y a encore un problème de performance..

Ce n'est pas toujours le cas parce que malheureusement:
- certains langages intègrent les threads mais pas les processus, donc c'est plus lourd pour les dev d'utiliser les processus.
- Windows gère mal les processus.

Oui, enfin quand on conçoit un langage, ce sont surtout les header eux-même qui sont un bidouillage: si tu remarques bien, aucun des nouveaux langages n'impose des fichiers de header.

Tu es habitué aux headers, OK, mais bon l’intérêt d'une violation aussi manifeste du DRY maintenant que les ordinateurs sont suffisamment puissant pour s'en passer, bof..

Bof, vu que tu peux générer un fichier d'entête automatiquement, c'est un "pour" très faible..

• la création de processus est trop coûteuse comparé aux gains de la parallélisation.

Les pools de process ça existe aussi, ce n'est pas réservé aux threads..

Et pour qui est de la dangerosité de la mémoire partagée, explique en quoi c'est un argument contre les process??

Et puis franchement ce genre d'argument philosophique n'a pas grande valeur du code ou un benchmark ok, sinon bof
c'est du préjugé, de l'optimisation prématurée..

et dire qu'une alternative au multi-threading sur un processeur multicore (qui est la norme aujourd'hui) est du multi-processus, c'est, comment dire, clairement de la mauvaise foi.

Peut-tu expliquer pourquoi tu dis ça? Le non partage par défaut du multi-processus me parait plus sain, et si tu peux toujours utiliser la mémoire partagée si tu en as besoin..

Bof, ton argument est faiblard: dans un projet il est facile d'avoir comme règle de codage: pas de unsafe a moins qu'il y ait une justification.
La règle "éviter toute les constructions foireuse du C++" est beaucoup plus compliquée a appliqué!

Faux,
1) il n'y a pas besoin de modéliser tout l'assembleur pour que ça soit utile dans le cas dont on parle

2) ça existe déjà je pense:
http://www.reddit.com/r/ReverseEngineering/comments/1jz3qv/formal_specification_of_the_x86_instruction_set/

Quel avantage par rapport à Nix / Nixos ?

Je crois que la différence principale est qu'ils utilisent Scheme au dessus de Nix.

Je pense qu'une façon de faire serait de modéliser le comportement des fonctions utilisées et valider le fait que le code assembleur ne contient pas de buffer overflow.

Ça ne marcherai pas avec tout les programmes assembleur, mais bon ça devrait marcher avec un nombre suffisant..

Le C++ n'est pas du C !

Faux! Le C++ n'est pas que du C, mais quand tu regardes pas mal de projet soit-disant C++, en fait c'est principalement du C et donc on se retrouve avec tout les problèmes du C.

Note que F# a un sacré handicap: Microsoft! Pas besoin de détailler je pense..

Dit autrement, a quand une implémentation d'openssl en rust ?

Tu rêve: si la sécurité était vraiment prise au sérieux, le C ne serait pas utilisé sur ce genre de projet: Ada ça existe déjà depuis longtemps..
Certes, Ada n’empêche pas de faire des erreurs de durée de vie des variable comme Rust, mais il a le mérite d'être mature et d'exister depuis longtemps et de résoudre 99% des problèmes du C ce qui
est déjà un net progrès!

Avec ta définition, un vieux langage ne pourra jamais être un bon langage.

Tel que la plupart des langages sont développés effectivement c'est le cas car quand les créateur cherchent a améliorer le langage (cf Python3) souvent les mises à jours ne prennent pas..

Après il y a des degrés et C++ a une dette technique abyssale, Ada moins par exemple.

La seule alternative potentielle ce serait le "go fmt": faire évoluer le langage en fournissant des outils pour simplifier le portage, problème: ça marche bien quand tu as du code simple, mais dès que tu utilise les macros, la reflection, un outil ne peut pas faire grand chose..

Parce qu'un bon langage ne devrait pas avoir des manuels de 700 pages et plus et des livres qui donnent les bonnes parties et les partie a éviter.

C++ n'est donc pas un bon langage même s'il est très puissant.

Lors du mariage, le maire ne demande et ne vérifie pas la sexualité du couple,

Je le croyais aussi, mais (à Nice?) un mariage a été annulé car le femme se plaignait du manque de relation sexuelle: apparemment il existe une loi totalement obsolète sur le sujet mais qui a été appliquée dans ce cas là..

Bof, pour préciser mon propos que l'homophobie est une forme de racisme: le racisme n'est pas à propos des races puisque biologiquement tout les hommes sont de la même race, donc le racisme devrait s’appeler "groupisme": la discrimination envers d'un groupe envers un autre.

Les groupes étant défini suivant des critères variables et flous, c'est souvent le pays d'origine mais pas seulement par exemple le racisme anti-métisse, donc ça peut aussi être la couleur de peau, mais pas seulement cf la religion, etc.
L'homophobie me parait donc être très clairement une forme de "groupisme".

Je ne vois pas en quoi établir l'évidence "établis un schéma de pensé ou le déni d’humanité à l’égard de l’homosexuel est possible".

Hum, remplace pédophile par raciste(*) et tu en pense quoi?

*: L'homophobie est une "variante" du racisme..