patrick_g a écrit 6420 commentaires

>>> 1) Pour moi 5 vies n'ont pas plus de valeur qu'une seule comme si au sens mathématique une vie avait une valeur infinie. Donc faire dévier le tramway serait pour moi considérer comme un meurtre car intentionnel.

Bon on va prendre un exemple extrême pour voir si tu est vraiment accroché à ton idée :

Tu est le capitaine d'un vaisseau spatial qui s'est posée sur une comète géante qui fonce vers la terre.
Si tu ne fais rien alors la comète va continuer son chemin et percuter la Terre. Elle est tellement grosse et va tellement vite que la Terre sera détruite et que toute l'humanité va périr.
Si tu actionne tes réacteurs la comète sera lentement détournée et elle s'écrasera sur un petit astéroïde. L'ennui c'est que ce petit astéroïde est habité par un vieux cosmonaute de 85 ans qui a décidé de finir ses jours sur ce bout de rocher dans son petit bidon pressurisé.
Ton alternative est donc claire :

Choix 1) tu ne fais rien et l'humanité est anéantie. 6 milliards de morts. Les femmes, les enfants, les familles, toutes les réalisations et tous les espoirs de l'humanité. Tout ceci fini pour toujours.

Choix 2) Tu déclenche tes réacteurs pour détourner la comète sachant que cela va tuer le vieillard sur son rocher.

Bien entendu si tu opte pour le choix 2) alors il faudra m'expliquer pourquoi à 5 vies contre 1 tu dis non mais à 6 milliards de vies contre 1 du dis oui. Quelque part entre les deux il se produit chez toi une transition non ? Soudain une vie n'a plus une valeur infinie n'est-ce pas ?

>>> 2) La valeur d'un pantalon est ridicule par rapport à la vie de la fillette.

L'intérêt de ce genre de question n'est pas tellement dans la réponse (évidente) que tout le monde apporte. Il est évident que la valeur d'un pantalon (disons 50 euros) est ridicule par rapport à la vie de la fillette.
La subtilité c'est qu'au moment ou tu réponds que tu t'en fiche de ton pantalon et que tu plonge pour sauver la fillette le philosophe fait un parallèle entre cette situation et celle de l'aide envers les pays pauvres.
Si moralement il est obligatoire de sauver des vies quand l'autre terme de l'alternative n'est qu'une perte monétaire pourquoi est-ce que tu ne donne pas tous le surplus non strictement vital de ton salaire ? Après tout des gens pauvres meurent de faim et de maladie tous les jours en Afrique et ailleurs. Leur situation est comparable à celle de la fillette et pourtant nous ne donnons pas (du moins la plupart d'entre nous) notre surplus de salaire pour sauver la vie de ces gens. Pourquoi ?
Là aussi un philosophe, Peter Unger, a mis en place une ingénieuse expérience de pensée (dite du "collectionneur de Mercedes") dans son livre "Living high and let die" : http://en.wikipedia.org/wiki/Living_High_and_Letting_Die

>>> Et pourquoi ne pas faire dérailler le tramway en aiguillant l'arrière sur la voie de garage ?

Cela ne sert à rien d'inventer des solutions, ce n'est pas une épreuve d'astuce pour voir si tu peux trouver des solutions originales (hurler pour alerter les 5 gars ou essayer de faire dérailler le tram).
C'est un questionnaire éthique ou il faut juste choisir entre les deux alternatives proposées.

Une note de 0/10 pour "Bienvenue à Gattaca" ? Hérétique !!!! Au bûcher !!!

Ou est-ce qu'on dit qu'il s'agit de libérer l'informatique ?
Là on parle juste d'être poli et de remercier les développeurs pour t'avoir donné le résultat de leur travail.

Et bien on pourrait soutenir que dans le cas du café lavazza, des chips flodor, des sièges ikea, etc c'est la production qui a payé ces fournitures et qu'il n'est donc pas pertinent de remercier.
En revanche dans le cas de Linux la production a utilisé une ressource gratuite qui a été mise en libre disposition par une communauté de développeurs. Il est donc poli de remercier non ?

Je trouve que tu accorde peut-être un peu trop d'importance à la notation des commentaires. Après tout quelle importance que tu sois plussé ou moinssé ? La majorité des gens, je pense, surfent en mode -42 et voient tous les commentaires. Ne me dis pas que c'est une puérile question d'égo non ?
Pour ce qui est de ton apport il est indéniable puisqu'à la suite de mon post tu a argumenté et tu m'a expliqué pourquoi Open Source Job Scheduler n'était pas un bon choix. Donc merci pour tes informations.

>>> après la ratification du Traité de Lisbonne, aucun Parlement national ni le Parlement européen ne pourra décider de la paix ou de la guerre

Pfff....mais quand est-ce que les nonistes vont arrêter de raconter des absurdités et des mensonges ?
- Ou est-il qu'il est marqué dans le traité de Lisbonne que le droit de déclarer la guerre est retiré au parlement français ? Nulle part.
- Ou est-il qu'il est marqué dans le traité de Lisbonne que la France pourra être entrainé dans une guerre contre sa volonté ? Nulle part.

et ça ? http://en.wikipedia.org/wiki/Open_Source_Job_Scheduler

A mon avis si la loi imposant un mouchard passe ce ne sera pas sous la forme d'un logiciel à installer sur ton ordi. Ce serait horriblement compliqué à mettre en place (impossible en fait).
La solution la plus simple serait d'obliger les FAI a mettre ce mouchard dans leurs box. Comme presque tout le monde utilise une {live|free|neuf}box c'est à cet endroit qu'il est le plus simple d'implémenter le mouchard.
Ceux qui disent que la loi serait inapplicable en pensant à un mouchard sur leur ordi ferait donc bien de se méfier et d'y regarder à deux fois.

>>> le HPC est loin d'être un domaine examplaire pour le libre, parceque mis-à-part linux pour le kernel, les stacks sotftware utilisées dans la majorité de ces machines sont propriétaires de chez propriétaire

Tu a raison mais on peut quand même citer la librairie OpenMPI (Message Passing Interface) qui est sous licence BSD et le système de fichiers distribués Lustre qui est sous GPL. Je crois que ces deux softs sont très utilisés dans le monde du calcul scientifique.

Quand à la problématique de la NSA c'est sûr qu'il faut être conscient que le top 500 ne recense que les ordis de ceux qui veulent bien passer le test LINPACK et soumettre leur résultat. Donc il doit manquer pas mal de machines.

Peut-être qu'on en parle moins cette année parce que tous les travers que tu cites sont exactement les mêmes aujourd'hui et que rien n'a changé depuis l'an dernier ?

Et pour le temps d'encodage ? Tu peux nous donner une idée de combien de temps ça met et des caractéristiques de ta machine ?

Alors j'ai regardé 2 cours :

Celui de Xavier Leroy est vraiment excellent et je le recommande. C'est très instructif et le rôle du compilateur est bien expliqué. La fin du cours est d'un niveau un peu trop hard pour moi mais les trois premiers quarts sont faciles à suivre.

Celui de Gilles Dowek est plus centré sur l'histoire du calcul et des algorithmes. Si vous avez lu cet excellent article de lui : http://www.futura-sciences.com/fr/print/comprendre/dossiers/(...) cela ne vaut probablement pas la peine de regarder aussi la vidéo mais dans le cas contraire vous pouvez y aller car on apprends des trucs et c'est intéressant historiquement par sa remise en cause du "miracle" des mathématiques grecques.

Sinon chapeau pour cette mise en ligne car c'est une ressource précieuse.

>>> C'est quand meme triste de voir que tes 14 derniers journaux sont sur le meme sujet.

Mais sinon sur les P members "qui n'ont jamais participé a quoique ce soit d'autre de l'ISO et se sont retire aussitot le vote sur Microsoft OXML passé" tu a un truc à dire ? ça te semble normal ou méga-louche ? Tu a le sentiment que ta boite a magouillé pour qu'ils votent en faveur d'OOXML ?

Je suis d'accord avec ton commentaire. C'est la première remarque j'ai eu quand j'ai voulu jouer avec un mec du boulot et que je lui ai montré wormux : "Mais pourquoi les persos ils sont a moitié suspendus en l'air? C'est pourri!".

C'est justement ça l'astuce ! Comme il le dit lui-même : "Très franchement nous avons peut-être _besoin_ d'avoir un BKL peu performant pour en finir avec lui."
Il veut remettre le vieux BKL non préemptible pour que ça emmerde les gens. Ainsi ils seront motivés pour se bouger la couenne et bosser sur la véritable suppression du BKL dans le noyau.

Je prépare une news sur les superordinateurs et le Cell.

>>> Depuis pas mal de choses ont changé

Mais pour le BKL je ne crois pas avoir vu passer de gros efforts pour l'enlever.

>>> rien ne dit que ca ne sera jamais envisagé

Bien entendu ils peuvent changer d'avis. Faut voir quand même que c'est un boulot immense et très casse-gueule. Si on se réfère à FreeBSD ils ont lancé un effort très déterminé pour supprimer le BKL (le projet SMPng) lors de la branche 5.x (5.0, 5.1, 5.2, 5.3, 5.4). Le travail a continué tout au long de la branche 6.x (6.0, 6.1, 6.2, 6.3) et maintenant qu'on en est à la branche 7.0 le boulot n'est pas encore fini.
Certes, comme Linux, le code important pour les performances est BKL-free mais il reste encore des appels disséminés dans le reste du code. Si je regarde la dépêche de Bapt à l'occasion de la sortie du 7.0 il est écrit : Poursuite de la suppression du « verrou géant » (aka "Giant Lock"). La majorité des composants importants sont désormais libres de "Giant Lock".
Si on parle de "la majorité" c'est bien l'indication qu'il en reste.

C'est dont un travail gigantesque et OpenBSD ne l'a pas encore vraiment commencé. A mon avis ils ont d'ailleurs parfaitement raison car leur créneau n'est pas la performances à tout prix. En gardant le BKL leur code reste simple et facilement auditable et c'est un gros plus quand on se concentre sur la sécurité.

Interview géante des développeurs OpenBSD suite à la sortie de la version 3.6 : http://www.onlamp.com/lpt/a/5302
Le journaliste pose la question de savoir quelle technique a été choisie pour le support SMP et Niklas Hallqvist réponds la chose suivante :

FB: What techniques have you chosen?

Niklas Hallqvist: Biglock. That means that while a process is executing inside the kernel, no other process gets access to it; instead they will spin until the first process leaves it. This is a bit crude, since some applications won't benefit at all from this kind of multiprocessing. However, most do, especially if things are set up with multiprocessing in mind.
The reason we have chosen biglock is that it is really simple, and simplicity is a prime objective if security is considered. Fine-grained locking is much harder to do completely right, and things like starvation and deadlocks are much more common. We are just too conservative to risk this.

>>> Concernant OpenBSD, ils sont encore au big lock et il n'y a pas actuellement de mouvement d'envergure pour changer cet état de fait.

Leur but est différent puisqu'ils ne cherchent pas la performance à tous prix mais la sécurité, la robustesse et la simplicité.
Passer au fine grained locking risquerait de déstabiliser le système pour un bon moment et ils estiment que cela n'en vaut pas la peine.

C'est tiré de cete article : http://lwn.net/Articles/273731/

Citation :
"once upon a time (prior to 2.6.16), semaphores were one of the primary mutual exclusion mechanisms in the kernel. The 2.6.16 cycle brought in mutexes from the realtime tree, and most semaphore users were converted over. So semaphores, which were once a performance-critical primitive, are now much less so".

Merci Floxy pour la modif !

Ce serait cool si un modéro pouvait changer la phrase :
"Ingo Molnar avait choisi la première solution mais Linus a opté pour la seconde".
Par la phrase :
"Ingo Molnar avait choisi la seconde solution mais Linus a opté pour la troisième".

>>> La 26 était en rc1 donc à un statut assez avancé. Elle est retardée de quelques mois ? ou on la sortira avec la perte de perf ?

Il faut bien voir que la perte de perf (c'est à dire l'augmentation des latences) est très théorique. Cela ne concerne que quelques parties du noyau qui sont sous le BKL et ces parties sont peu critiques pour les perfs et très peu utilisées.

Linus souligne que "The core kernel, VM and networking already don't really do BKL".

Ah non là c'est bien Jonathan Corbet qui s'est coltiné le travail : http://kerneltrap.org/mailarchive/linux-kernel/2008/5/16/184(...)