reno a écrit 3881 commentaires

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 ]

> vous dîtes "Laïneuks" vous ?

Loupé: les Anglais respectent la prononciation des pays d'origine (pas comme les Français) donc ils sont aussi sensé dire "Linuks", cf wikipedia qui a même un extrait audio sur le sujet!

<soupir un linuxien devrait le savoir>
Une bonne idée est une bonne idée, quelque soit le nombre d'utilisateurs!

Le comportement du C de masquer les débordements entier est une connerie, j'espère que le langage qui le remplacera un jour ne reproduira pas cette erreur..

Pour les débordements, tu peux rajouter des tests dans tout les CPUs..
Mais ils augmentent la taille du code, utilisent des ressources pas beaucoup étant non pris normalement), le coté élégant du MIPS est que cela ne coute rien (*)!

*: enfin dans le cas normal de non-débordement.

> C'est quoi le problème concernant le prix Hugo pour le livre "Harry Potter et la Coupe de feu" ?

Que ce n'est pas un très bon livre, juste correcte sans plus mais que "le trône de fer" est excellent..
Le seul bémol du trône de fer est que c'est une série/saga qui n'est pas facile à suivre (beaucoup de personnages, de livres) et qu'elle ne sera probablement jamais finie..

Tout à fait:
1) avant les ARMs étaient limités à 4Go de mémoire totale, maintenant avec la dernière variante de leur jeux d'instruction ARMv7 ils sont uniquement limités à 4Go par processus, mais ils peuvent avoir jusqu'à 256Go de mémoire totale (40bit).
Ce qui fait que s'ils veulent vraiment cibler les serveurs, il faudra qu'ils changent encore leur jeu d'instruction pour autoriser plus de 4Go par processus..

2) le MIPS possède 2 variantes de chaque instruction entières une avec ou sans TRAP en cas de débordement entier.
Le TRAP est grosso-modo l'équivalent d'une exception mais gérée directement par le CPU.

L'avantage est que, en Ada par exemple, cela permettrait de générer une exception en cas de débordement entier sans avoir à rajouter de code dans le chemin 'normal' (sans débordement): gain en efficacité..
Et je trouve que le comportement d'Ada bien plus sain que celui du C qui peut causer des problèmes de sécurité, donc j'aime bien le MIPS..