reno a écrit 3886 commentaires

>> return n'est pas un mot clé. Dans la mesure où le langage est fonctionnel et où toute expression et tout statement retourne une valeur, ça serait inutile d'avoir ce mot clef <<

Ca c'est très discutable, dans Eros il se sont rendu compte que dans certaines fonctions la valeur retournée n'aurait pas du l'être, ce qui peut être génant dans certains cas (capabilities).

Personellement je trouve que ce n'est pas une bonne idée d'avoir la derniere valeur d'une fonction retournée par defaut, je prefere que ce soit explicite.
Si tu considère 'return' comme étant trop lourd visuellement, alors '^' comme Smalltalk est un bon compromis..

Haskell, c'est le nouveau Lisp: c'est l'avenir depuis très longtemps et cela le restera..

Pour Haskell, une critique sérieuse est que l'évaluation paresseuse par défaut rend difficile l'évaluation des performances: des petites modifications peuvent induire des grandes variations de performances..

L'autre critique sérieuse est que ce langage est difficile à apprendre.

>> En fait Go n'est qu'une ré-écriture de Common Lisp <<

Ahem, tu oublie "juste" le typage statique..

On n'est pas Vendredi, mais je te répondrai que s'ils siphonnent les utilisateurs des autres distributions, c'est qu'ils doivent faire un *truc* de mieux que ces autres distributions.

Ce truc peut être une configuration par défaut (intégration), du marketing, etc: peu importe, rien n'empèche les autres distributions de se battre sur ce domaine:
- il n'est pas trop difficile de réutiliser la conf par défaut et même de la remonter upstream si Ubuntu ne le fait pas..
- le marketing pour Ubuntu n'est pas très agressif, donc il ne doit pas être bien difficile de le concurrencer.

Conclusion, peut-être que les autres distributions ne cherchent même pas à concurrencer Ubuntu car le desktop ça paye pas (comme RedHat le dit depuis longtemps), donc plutôt que de critiquer Ubuntu/Canonical pour ce qu'ils ne font pas, tu devrais être content qu'ils existent et même espèrer qu'ils arrivent à être profitable car à ce moment là, on peut espèrer l'arriver d'une vrai concurrence sur le desktop Linux..

Il me semble que pour le moment Canonical est déficitaire, s'ils restent déficitaire, tôt ou tard tes souhaits de disparition d'Ubuntu seront exaucés..

Je ne comprends pas: si tu dis qu'il existe un "lien" VDPAU -> VAAPI, je ne vois pas ou est le probleme.

Ou alors tu mets les fleches dans le mauvais sens..

XFS a eu un gros bug qui pouvait faire perdre completement la partition, j'imagine que cela a du refroidir beaucoup l'adoption.

Ca plus les interrogations sur la santé de SGI, de ce que j'en sais ce sont les raisons principales.

Bon ce bug a été corrigé il y a très longtemps et XFS est toujours maintenu donc ces raisons ne sont plus valables, je pense donc qu'il s'agit principalement d'un manque de "publicité": l'industrie informatique fonctionne vraiment comme la mode.

Dans le même genre, Ada n'a jamais percé même après qu'il y ai eu un compilateur gratuit (libre).

Bah, ils sont déjà des "crypto-communistes": ils utilisent de temps en temps https..

Ce qui montre bien que ce n'est pas vraiment un probleme d'utiliser du chiffrement si l'interface utilisateur est simple..

C'est en Anglais, mais c'est sur le même sujet:
http://everydaylht.com/2010/11/26/kde-4-6-beta-1-a-first-look/

>> Bref, en tant qu'homme, je suis reparti honteux que d'autres hommes, que d'aucun qualifierait de mes semblables, puissent avoir commis des actes de violence, envers leurs femmes, en présence, voire a l'encontre même, de leurs enfants... <<

Tu as le droit d'avoir des sentiments illogiques, mais pourquoi être honteux d'acte de violence avec lesquels tu n'es relié en rien? Masochisme?

Certes, et comme dans les agressions entre époux, on est dans le passionel..
C'est pour cela que la mise en pratique me parait difficile, et puis il y a aussi la présomption d'innocence.

> je déplore fortement la non-popularité des langages fortement typés

Ca dépend de ce que tu appelles "popularité": C++ et Java sont deux langages a typage fort (et statique) très utilisés.

Ils ne sont pas aimés parce que C++ est une bouse infame et que Java a d'autre problemes trop simple, trop verbeux, appartient à Oracle..

Note que leur remplaçants potentiels respectifs D et Scala sont tout les deux aussi fortement et statiquement typés, mais avec inférence de type locale ce qui réduit le nombre de déclaration de type.

>> Au passage, il y a là un vrai problème. Pourquoi est ce à la victime de quitter le foyer ? <<

Tu oublie un "détail", il me semble qu'il vaut mieux que le mari ne sache pas ou se trouve sa femme ce qui réduit les risques de récidives..

Je comprends ta question, mais en pratique cela me parait difficile..

>> Ah et puis aussi, supprimer le masculin/féminin de la langue française, et utiliser un nouveau genre, le neutre. Ca serait un message fort ! :-P <<

Il est vrai que donner un genre à des objets inanimé est vraiment bizarre, et dans le même genre pour avoir une langue plus logique, on devrait aussi remplacer les "ê" par des "è".

C'est un changement mineur, donc il ne devrait pas y avoir pour de defenseur de la langue(*) pour s'y opposer, non?

Ah? Peut-être que si..


*: plus familièrement connu sous le nom d'uraniseurs de musca domestica.

>> Déjà je trouve dommage d'avoir mis le mot "pute" dans une lutte féministe, comme si les putes, les vraies donc, n'avaient pas le droit d'être protégées de la violence et comme si, déjà, elles n'étaient plus des femmes. <<

Je ne trouve pas ça seulement "dommage", mais carrèment choquant comme nom d'association!
Encore plus pour une association féministe..
Ce qui fait qu'à priori, je ne leur accord *aucune* crédibilité.

Bôf un Linux "standard"; ça existe ça (*)?

Tu n'as qu'à testé sur d'autre distributions et leur retourner le résultat plutôt que de tiqué..
Pourquoi ce serait à eux de faire le boulot?


*: Ah si on me souffle dans l'oreillette qu'il y a LSB, on me souffle aussi qu'on n'en entend pas beaucoup parler ces temps ci..

Sur un article sur LWN, j'ai lu qu'il critiquait un changement de l'implémentation de memcpy dans glibc car ce changement faisait apparaître des bugs (existant mais caché dans l'implémentation précédente), suivant sa philosophie de rester compatible *de fait* pas juste en théorie.

Mais la, ce changement du scheduler, apparemment Con Kolivas avait fait quelque-chose de similaire dans BFS et avait trouvé que cela induisait des regressions: apparemment certaines applications ont des bugs exposés par le changement du scheduler.

Si ces mêmes bugs sont rapportés sur le patch pour le Linux 'officiel' je pense que le patch ne sera jamais appliqué..

Je n'ai jamais rien compris avec les dn, on, etc.

Quand on regarde LDAP, on se dit que finalement le XML c'est lisible (quoi que coté schema, les developpeurs d'XML ils ont pas fait fort non plus).

Effectivement, a la reflexion, Wayland fait aussi gestionnaire de fenetre (en tout cas partiellement car il ne gère plus la décoration) et pourra donc masquer la fenetre et envoyer un signal au client.

Mes autres critiques concernant la duplication du code d'X dans les toolkits demeurent fondées je pense..

Ce que je trouve amusant, c'est qu'une des critiques que je trouve fondée envers X est que le copier/coller ne fonctionne pas assez bien, il ne fonctionne pas très bien car X ne fait pas grand chose dans les copier/coller le vrai traitement étant répartit dans les toolkits, dont certains ont des bugs d'interopérabilités..

Donc remplacer X par Wayland qui fait encore moins de chose ce qui implique de dupliquer le code d'X dans les toolkit, quelque chose me dit que ce n'est pas prendre le bon chemin!

PS: je ne dis pas qu'X est parfait loin de la: il serait possible d'integrer NX, rendre obsolete ce qui n'est plus utilisé dans X.
Le redemmarage a chaud d'X serait aussi interessant, mais me parait plus difficile, et c'est aussi un probleme de toolkit que d'X.

> Au contraire, une des caractéristiques de Wayland, c'est l'abandon de la couche réseau

Ce qui est bien pour ça que ceux qui comme moi apprécie le coté 'transparence du réseau' d'X ne le voient pas comme un remplaçant d'X tant qu'on n'a pas rajouté cette fonctionnalité.

Quand on rajoute cette fonctionnalité dans les toolkits, la question se pose alors: que gagne-t'on?

On a déplacé des fonctionnalités d'X aux toolkits, ce qui induira bien sûr des tas de regressions (nouveau code == code buggé, au moins temporairement) sans simplifier vraiment le système.. On peut même considèrer que c'est une complication du système car tu remplaces une couche fournie par X par N versions: autant que tu as de toolkit..

Avec Wayland, je me pose la question aussi: quand tu as une application qui se plante, comment se débarasser de la fenetre?

> Wayland, j'ai testé, c'est extrêmement fluide!

Les applications de BeOS étaient *beaucoup* plus fluide que tous les autres OS, mais BeOS est mort quand même..

Pour ce qui est des parties obsoletes d'X qui te traumatisent (et apparement aussi l'auteur de Wayland car ils en parlent dans la FAQ), il suffirait d'incrementer la version majeure du protocole X en ne gardant que les parties d'X utile..

Hein? Eiffel a été créer par Bertrand Meyer, il ne me semble pas qu'il ai travaillé à l'INRIA (ce n'est pas marqué sur wikipedia en tout cas).
L'INRIA propose peut-être aussi une implémentation d'Eiffel, mais c'est différent..

D'accord mais j'avais lu quelqu'un qui expliquaient que pour redemmarer X il y avait ce qu'il faut au niveau du protocole, mais que les applications/toolkits n'implémentaient pas la réponse à la demande de toute ré-afficher..

Peut-être que changer le 'middleware' (X, Wayland), donnera un coup de pied au cul aux toolkits/applications pour implémenter la partie manquante, mais c'est loin d'être évident..

Bref changer le middleware ne résoud pas forcément le problème, si le problème viens des applications et/ou des drivers..

Microsoft qui arrête IronPython, IronRuby et les développeurs de JRuby qui ont quitté Sun^WOracle..

>> Pour les utilisateurs, cette concurrence sera certainement bénéfique <<

La concurrence entre plusieurs solutions a des avantages ET DES INCONVENIENTS.
Ne parler que des avantages, c'est être partial (ne parler que des inconvénients aussi bien sûr), un exemple des inconvénients: Google a dut retardé son port de Chrome/Chromium sur Linux a cause de la présences de ces solutions concurrentes ce qui complique l'écritures d'un 'bac à sable' pour Linux:
http://blog.chromium.org/2009/06/google-chrome-sandboxing-and-mac-os-x.html

Dans ce cas particulier, si je comprends l'interet d'avoir 2 type de mécanismes de sécurité: un (complexe mais puissant) qui se base sur des labels, un (plus simple) qui se base sur les noms de fichier, je ne comprends pas trop pourquoi il y a besoin d'avoir SELinux et SMACK, ainsi que TOMOYO et AppArmor, plutôt que juste une seule implémentation de chaque type..

Oui enfin tes analyses elles ne valent pas grands chose..

> Le bug d'Ariane : on a une erreur, on désactive

Uhm, sais-tu que le traitement devait se faire en un temps très court (bin oui au décollage d'une fusée, on n'a pas beaucoup de temps pour réagir)?
C'est surtout un problème de tests non (ré)effectué..


> le bug SSL Debian : erreur, on commente le code;

Oui, enfin de mon point de vue les programmeurs initiaux avaient aussi leur responsabilité dans l'affaire: l'utilisation de variable non-initialisée est suffisamment rare pour que tout bon programmeur avertisse les mainteneurs ultérieurs par des commentaires et nom de variables adéquats, ce qui je crois n'était pas le cas..

Pour le reste, oui pour avoir du code sécurisé il faut que les développeurs connaissent bien le langage, mais cela ne veut pas dire qu'on est obligé de se limiter au C..

> - La performance de réponse à une requête : PostgreSQL est jugé plus performant dans la plupart des cas

Y compris sur les grosses bases de données?

[ je ne trolle pas: je me renseigne ]