L'article d'Agoravox est complètement faux. Non pas dans les faits qu'il cite, mais dans leur interprétation, et témoigne d'une méconnaissance assez forte du système monétaire international.
Les accords de Bretton Wood n'ont pas pour but de placer le dollar comme monnaie étalon, mais ont pour but de permettre aux pays émergeant et à ceux dont la monnaie a été fortement dévalué pendant la guerre de s'appuyer sur la monnaie la plus stable au sortir de la guerre : Le dollar. Grosso-modo ca permet de garantir sa monnaie contre du dollar. Mais rien n'empêche un pays dont l'économie est forte de placer sa monnaie sur des marchés de change et d'obtenir un prix basé sur le système traditionnel d'offre et de demande.
Les pays n'achètent que très rarement du dollar, le plus souvent ils achètent des T-bonds (c'est à dire des bonds du trésor émis par le gouvernement américain). Ces bonds existent à plus ou moins long terme (de 10 à 30 ans) et permettent aux pays de limiter en partie leur inflation. Il existe aussi des Notes (treasury notes) pour la dette à court terme (2 à 5 ans). Les intérêts sont payés tous les six mois, le principal est rendu à échéance du coupon.
Ce qui se faisait avant est que les pays qui possédaient des bonds du trésor utilisaient le versement des intérêts pour racheter d'autres bonds. Notablement la Chine qui se servait de ce système pour maintenir le Yuan à un prix raisonnable (le Yuan n'étant pas présent sur les marchés de change sont prix et défini de facto par la quantité de bonds que possède le pays). Aujourd'hui la Chine possède plus de 30% de la dette à court terme des US.
Seulement il s'est produit un certain nombre de choses qui ont cassé ce système. Tout d'abord un bon nombre de pays "émergeant" qui assuraient leur monnaie fragile sur le dollar ont émergés et n'ont plus besoin de la garantie. De plus les manœuvres de M Bush jr sur le système de retraite ET sur le health care ont rendus les bonds nettement moins intéressants. Ensuite le dollar, pénalisé par l'industrie ralentie des US s'est cassé la figure face aux autres monnaies fortes des marchés de change. De fait il est devenu nettement plus intéressants d'acheter du dollar directement que de chercher à acquérir des bonds. Comme en prime tous les pays ou presque possèdent déjà des bonds, en cas de besoin de dollars, il est plus facile d'attendre leur arrivé à terme ou de revendre les bonds sur les marchés que de se donner la peine d'aller acheter du dollar sur les marchés. Les Etats Unis se sont donc retrouvés dans l'incapacité de financer leur propre dette intérieure. Alan Greenspan en jouant des taux d'intérêt comme un virtuose a réussi à limiter les dégâts pendant près de cinq ans (de 2002 à 2007) mais son départ, un peu forcé, a mis fin au miracle et aujourd'hui le problème des subprimes (hausse des taux automatique sur les emprunts contractés indexés sur les taux d'intérêts ) fait qu'un bon nombre d'américains se retrouve dans une situation précaire.
Au final, ce qui se passe est que tout le monde a du dollar, mais que plus personne n'en veut. Même les pays qui engrangent du pétrodollar par milliards s'empressent de les revendre contre du Yen/Euro dès qu'ils le touchent pour éviter de perdre trop d'argent. ce qui aggrave encore la chute du dollar.
Donc pour "sauver" le dollar, il faudrait non seulement que les États-Unis réussissent à empêcher des marchés de matière première de passer en une autre monnaie que le dollar (et pour les métaux c'est déjà foutu; or ce sont eux qui subissent la plus forte hausse des prix) mais il faudrait aussi qu'ils arrivent à dynamiser leur industrie/baisser leur taux d'intérêts et qu'ils arrivent à convaincre les pays extérieurs de recommencer à acheter du bonds. Déclarer une guerre à un pays de plus (surtout un pays comme l'Iran) serait désastreux à tout point de vue. Tout d'abord parce que même si ça dynamiserait l'industrie interne, le gouvernement est à cours de liquidités il lui faudrait donc émettre en masse des coupons de dette (dont personne ne veut et qui sont déjà responsable d'une crise de l'immobilier à l'heure actuelle), ensuite parce que des pays comme la Chine, la Russie, l'Inde et le Brésil qui sont de gros producteurs pétroliers sont déjà en pourparlers d'ouverture de marchés en Euro et que déclarer la guerre à ses pays est impensable (à moins de vouloir réellement une troisième guerre mondiale, dont les US qui n'ont plus la puissance industrielle qu'ils avaient en 1940 ne peuvent pas franchement se remettre).En plus la Chine et l'Inde possèdent suffisamment de bonds pour inonder les marchés et empêcher toute émission du gouvernement de se faire avec succès. Enfin parce que même si le but visé est atteint (les marchés du pétrole restent en dollars) rien n'empêchera les pays de revendre lesdits dollars contre d'autres monnaies, ce qui ne fera qu'aggraver la situation du dollar faible.
La volonté des US de garder les marchés du pétrole en dollars est purement symbolique, elle permet de minimiser la crise. Tant que le dollar reste une monnaie de référence, on peut essayer de convaincre que la crise n'est que passagère et que l'on ne s'engage pas dans une grande dépression.Si les marchés pétrole s'ouvrent à d'autres monnaies, la confiance des marché de change risque de s'effondrer ce qui achèverait le dollar.
Après de courts tests, le seul cas chez moi ou ca va plus vite en passant par xen est si a) on est court en mémoire ET b) le compilateur JIT est arrêté.
En ce qui concerne la config Erlang : il n'y a pas de règles ou de trucs. Ca se configure appli par appli.Par contre la config Ejabberd est un poil plus complexe à maitriser. Les logs sont assez problématiques à comprendre et à mettre en place correctement. Pour le reste je suis contraint de te renvoyer au manuel. il y a des pages et des pages de config. Mais ce n'est pas très compliqué. CF http://www.process-one.net/docs/ejabberd/guide_en.html#htoc9
Après si tu as des questions plus spécifiques, tu peux me joindre par email ou via les messages privés.
Pourquoi ça ronge comme de l'acide les hydrocarbures ?
La plupart des hydrocarbures sont :
- Corrosifs
- Cancérigènes
- Chargés en métaux lourds (notablement le plomb)
- Solvant des graisses (va avec corrosif, mais ajoute un bonus)
- Neurotoxiques (à cause du plomb d'une part, mais aussi à cause des molécules aromatiques qu'ils contiennent souvent)
Plus deux trois trucs évidents comme, inflammables, toxiques et volatils (bon sur le dernier point, la godasse peut rien pour vous)
A titre d'exemple un homme placé sans protections dans une cuve de pétrole brut est dissout en quelques heures...
Donc pour les gens qui sont sans arrêt exposés à ce genre de produits, la protection est une bonne idée.
sinon coté "scalabilité" d'ejabber, c'etait pas frappant pour le moment, j'ai du mettre plein de xen sur un seul serveur avec un ejabberd par instance pour que ca tienne le choc, sinon ca partait en sucette
GNI ???? Tu as mis tes machine virtuelles jabber dans d'autres machines virtuelles ? Et ca marche mieux ?
A mon avis il y a un gros problème avec ta config erlang.
Mon serveur, qui n'est pas un foudre de guerre même si il a 4go de ram encaisse sans broncher près d'un million de demande de connexion par minute (en test labo hein, il y a pas 300 utilisateurs réels sur la bécane). Je pense qu'il pourrait encaisser plus, mais c'est la connexion qui limite.
Bien évidemment, notre brave McCreevy ne pense pas à Cliff Richard ou Aznavour, ou Johnny Halliday, mais "plutôt aux milliers de musiciens de studio anonymes (...) Ceux-là ne percevront plus aucune redevance liée à leur contribution à ces enregistrements, alors qu'il s'agit souvent là de leur seule retraite".
Le pauvre, il est mal renseigné. les artistes indépendants restent propriétaires de leurs œuvres dans la majorité des cas. De fait le décompte des 50 ans ne commence qu'à leur mort.
Seuls les artistes qui ont signés des contrats "employés" avec des boites de prods ou des majors voient le décompte commencer dès la sortie du disque, car c'est alors la maison de disque qui devient propriétaire des droits.
Tout va donc bien pour les petits. M McCreevy peut dormir tranquille.
A mon sens le meilleur rapport qualité/prix c'est la PROMISE SATA300 TX4 .
Son gros défaut est d'avoir un bios intégré un peu vampire qui n'aime pas trop quand il y a d'autres contrôleurs SCSI/SATA sur le port PCI. Plus rarement on peut avoir des problèmes avec le contrôleur intégré à la carte mère si celui-ci a des options avancées (Raid logique onboard, couplage de chipset sata en pagaille etc.)
Ce défaut peut être résolu en effaçant pure et simplement le bios de la carte.
Ses avantages sont les suivants :
a) C'est une vraie carte Sata, comprendre qu'elle gère vraiment toute la pile SATA toute seule, ce n'est pas une carte qui fournit un peu de câblage et qui se repose massivement sur le pilote logiciel et le CPU pour traiter les demandes.
b) Elle est très bien reconnue et bien supportée par Linux et BSD.
c) Elle n'est pas trop chère.
d) Si on n'a pas d'autres cartes contrôleurs dans al machine, le bios offre quelques options intéressantes.
En ce qui concerne Silicone Image, ceux basés sur un Sil3112 sont passables, mais un peu vieillot, par contre pour les autres chipsets il faut vérifier qu'il s'agit bien de contrôleurs complet. Pas de cartes qui repassent tout le boulot au CPU.
Finalement, si c'est pour faire du raid, il faut taper dans le haut de gamme direct. Quasiment toutes les cartes SATA en PCI font du raid logiciel via le pilote. Autant activer le raid logiciel avec les outils Linux à ce moment là, on a souvent de meilleures perfs et une consommation CPU moindre...
Mon tarif est de 50€/h. Pour le décrassage complet de l'ordinateur et la mise en place d'une solution de protection efficace.
Je peux faire un prix pour les amis mais je refuse catégoriquement de bosser sur des XP piratés (remplir le tonneau des danaïdes ca me tente moyen).
Je prévient que pour éliminer un spyware bien accroché (planqué derrière des fichiers invisibles et déclaré comme devant être restauré en cas d'effacement) il faut en moyenne 4 à 5h pour récupérer le PC et le protéger, ainsi que pour faire un peu de pédagogie vis à vis de l'utilisateur.
Sous Linux/BSD je suis nettement moins cher (et gratuit pour les amis).
A noter que la personne qui a payé 250€ pour récupérer ses données est nettement plus sensible quand on lui dit qu'il ne faut pas cliquer sur tout et n'importe quoi ou installer les petits trucs rigolos qui trainent sur internet. Statistiquement la personne qui ne paye pas se reprend un virus/spyware par sa propre faute dans les deux mois...
La plupart des boites et/ou indépendants m'expliquent qu'ils préfèrent payer pour du windows car il y a une multiplicité de supports commerciaux. Alors ma foi, si ils préfèrent payer...
Stravinsky : L'oiseau de Feu dirigé par Pierre Boulez (pleins de versions, toutes excellentes). La musique la plus violente jamais écrite (le grind core peut aller se rabiller)
Beethoven, symphonie n°2 : moins connue que la scandaleuse 9 mais un vrai régal. A prendre dirigé par Karajan avant 1965 ou par FurtWängler si tu trouves.
Mozart Symphonie 41 "Jupiter" dirigée par Seiji Osawa ou Karl Bohm (surtout pas la version de Karajan) : quand Mozart s'ennerve...
Mauvaise logique : la demande étant faite par une célibataire, l'avis du conjoint actuel n'a pas d'importance
Je ne suis pas du tout d'accord, il y a une différence fondamentale entre rencontrer une personne qui a un enfant (et qui dans le meilleur des cas va pouvoir dissimuler cette information quelques semaines) et vire depuis des années avec une personne qui d'un seul coup sans demander votre avis ou presque a un enfant de 2 à 4 ans. Dans un cas l'enfant peut s'interposer dans la relation et l'empêcher d'aboutir, dans l'autre cas on a un facteur qui peut briser une relation de couple durable avec tous les traumas directs et indirects que cela peut causer à l'enfant.
Choisir de vire avec une personne qui a un ou des enfants et se retrouver du jour au lendemain lié à un enfant de façon durable sont deux choses distinctes au niveau psychologique. Je comprend tout à fait la prudence des services sociaux en la matière.
Sun ne fourni plus libc.A depuis solaris 10. Ce qui est assez enervant, par exemple quand on veut compiler en static un outil de verification d'intégrité.
Oui, enfin Solaris prend une approche résolument différente des Unix classiques depuis la version 10. Notamment sous Solaris 10 et OpenSolaris il est assez fortement recommandé de ne pas mettre /usr sur une partition à part justement pour des questions de liens dynamiques. En fait il semblerait que Solaris soit bien décidé à tuer sur ses systèmes toute notion de liens statiques.
Je me mêle trente secondes de ce thread pour (tenter) d'expliquer en quoi bash comme shell root c'est mal.
Le shell root est parfois la seule arme qu'il reste quand on a un gros problème sur une machine, notament en cas de corruption de disque dur et de problème sur la table de partition.
Ce qui casse le plus les pieds à un admin (et de loin) et de devoir descendre en salle machine, voir de devoir prendre un taxi pour aller jusqu'à la salle machine quand un truc part en vrille. le but est donc d'avoir un système totalement indépendant du reste sur le /. C'est pour celà que l'on a un /root et non un /home/root.
Dans la plupart des Unix, comme dans FreeBSD et OpenBSD l'intégralité du contenu de /sbin et la majorité du contenu de /bin est linké en statique et est aussi light que possible (par exemple pas de dépendance à la libc). Le but du jeu étant de pouvoir travailler et tenter de récupérer des données sur un système dont on est même pas sur qu'il reboote. La solution LiveCD a deux inconvennients : tout d'abord elle necessite un accès physique à la machine (ce qui est lourd) et ensuite elle requiert de devoir redémarrer la machine, ce qui est potentiellement dangereux. Une carte RAID qui envoit message d'alerte sur message d'alerte peut parfaitement décider au reboot que les disques sont inutilisables et les achever ou refuser de les rendre accessible.
Dans ce genre de cas, je suis personellement assez content d'avoir tout un BSD minimaliste et linké statiquement sur ma machine, ce qui me permet de récupérer un maximum de données même si le /usr est mort ou si le /var fait des siennes.
On peut faire une version minimaliste et lié en statique de bash, mais elle sera toujours plus grosse que son équivalent sh/csh et donc plus sensible aux corruptions et ensuite bash a une facheuse tendance à remplacer certaines commandes Unix de base par les siennes propres. La bonne façon d'invoquer bash sur un système à l'agonie est bash --noprofile --norc --noediting --posix. Mais si on fait celà il n'apporte vraiment pas grand chose de plus que csh...
Tiens voilà la liste des commandes à passer pour :
- Télécharger l'ensemble des mises à jour de FreeBSD 6.x à FreeBSD 6.3
- Vérifier la cohérence de la configuration avant la mise à jour
- Valider l'ensemble de la mise à jour du kernel space avec ou non installation et activations des modules kernel et des docs associées.
- Valider l'ensemble de la mise à jour du user space et la mettre en place :
# gpg --verify freebsd-update-upgrade.tgz.asc freebsd-update-upgrade.tgz
La nouvelle version de freebsd-update peut alors être extraite et lancée comme suit :
# tar -xf freebsd-update-upgrade.tgz
# sh freebsd-update.sh -f freebsd-update.conf -r 6.3-RELEASE upgrade
# sh freebsd-update.sh -f freebsd-update.conf install
Le système doit alors être redémaré pour mettre en place le nouveau kernel
# shutdown -r now
Enfin freebsd-update doit être lancé une dernière fois pour mettre à jour l'espace utilisateur et la machine doit etre redémarrée une fois de plus.
# sh freebsd-update.sh -f freebsd-update.conf install
# shutdown -r now
Mise à jour de ma machine FreeBSD 6.1 en 12mn30sec sans aucun problème. Les fonctionnalités web (Apache et Yaws), base de données (Postgres et MySQL), mail (Postfix, Dovecot, Majordomo, RoudCube), authentification (Cyrus SASL, OpenLDAP, ssh) et le système se portent bien.
Mise à jour faite à distance sur une machine Dedibox.
Je ne saurais en aucun cas être tenu responsable des dégats si un utilisateur frustré par ce poste s'amusait à tenter le même genre de chose sur une distrib Linux....
Honnêtement, voyons les choses en face, les deux distribs sacralisées par RMS dans ce thread (Ututo et Gnewsense) sont
a) Inutilisables
b) Farcies de logiciels proprios.
Inutilisable dans le sens ou elles ne disposent pas de suivi concret, les logiciels possédants des failles de sécurité mettent des plombes à être mis à jour, les diverses limitations "pro-libres" leurs coupent les ailes et la doccumentation est inexistante dans la plupart des cas et non traduite dans les autres. Pour finir la base utilisateur est tellement faible que trouver une solution à un problème particulier nécessite soit des connaissances très complètes dans le système Linux et la distribution soit de "casser" ou de passer outre le système d'installation et de gestion des paquets de la distrib.
Farcis de logiciels proprios dans le sens ou ces deux distributions incluent en standard plusieurs outils pour lire et créer des PDF (soumis à brevet) ou pour lire et créer des fichiers audios et vidéos suivant des standards dérivés du MPEG-Group. Gnewsense va un peu plus loin en empéchant sa version de Firefox (Burning Dog) de vous rediriger directement vers le site d'Adobe quand il tombe sur du contenu Flash, mais honnêtement ca ne change pas grand chose, et de toute les façons le Firefox de Ututo le fait sans complexe.
Bien entendu les deux distribs lisent courament le système de fichier FAT (soumis à brevet) et GNewsense utilise la version CDDL de cdrecord dont la compatibilité GPL a été plusieurs fois questionnée (pour des raisons au moins aussi stupide que le thread dont nous sommes en train de parler)
Donc OpenBSD inclut des ports non libres : Vrai
Celà peut encourager les utilisateurs à utiliser des logiciels propriétaires : Vrai
C'est pour celà que RMS ne peut pas recommander OpenBSD : Faux, celà ne l'a absolument pas empéché de reccomander des distributions qui incluent, utilisent ou poussent à l'installation de logiciels non libres.
RMS joue le sourd et aveugle (mais pas muet malheureusement) de façon totalement hypocrite sur ce coup là : Vrai.
C'est ce que je disais plus haut, et à quoi tu répondais "euh non, pas du tout": tu peux toujours exécuter le programme et voir ce que ça donne
Ce qui m'ennuie avec cette phrase et qu'elle induit violamment en erreur. Dénombrer exhaustivement puis évaluer tous les états d'un programme n'est pas du tout équivalent avec l'execution d'un programme sur l'ensemble des jeu de données possibles à raison d'un million d'execution par jeu. Dans le second cas rien n'indique que l'on a effectivement couvert tous les états possibles. Un état particulier peut très bien ne se produire que dans certaines conditions très précises.
Par exemple si on cumule des arrondis au delà de la limite du CPU, on peut parfaitement avoir un programme qui calcule juste sur un ordinateur et faux sur celui d'à coté.
De plus il n'est pas question d'executer ici le programme, mais de valider ses etat. Celà se fait le plus souvent de façon totalement extérieure au programme. Enfin il ne s'agit pas de valider le programme pour un seul et unique jeu de données, mais pour un ensemble de données toutes bornées.
Avec la doc du CPU et du compilateur il est souvent à peine plus complexe de valider un état pour X appartenant l'ensemble des entiers 32 bits que pour X = 5
C'est un résultat relativement inutile
Si on ne pouvait prouver que sur un seul jeu de données oui, mais comme on peut prouver sur n'importe quel jeu de données borné à partir du moment ou les variables dans les états sont elles-mêmes bornées c'est très très pratique. Comme aucun ordinateur n'a de mémoire ou de registre infini on peut démontrer au cas par cas sur n'importe quel problème. Il arrive même (approche orthogonale aux types) que l'on prouve vrai un programme qui traduit un algorihtme d'un problème indécidable par ce que l'on sait que l'on va forcément se prendre un Out of Memory ou un NaN avant de rentrer dans les cas problématiques.
Un bonne exemple de prblème indécidable qui n'empêche pas des programmes d'être prouvé est le calcul par éléments finis. Si l'utilisateur du programme sort des etats calculables, le programme lui envoie un joli message d'erreur l'invitant à revoir sa copie. Et on construit des avions parfaitement fiables avec ces trucs là...
Pour conclure de mon côté, je renverrais les lecteurs intéressés, s'il en reste, vers le théorème de Rice pour plus de détails:
Une fois de plus le Theorème de Rice démontre que l'on ne peut pas écrire un unique programme P tel que pour tout programme source SPx on puisse avoir P(SPx) -> le programe se termine ou non ET le programme est conforme aux specs. Il ne dit absolument pas que pour un programme quelconque spécifié il est impossible d'écrire un autre programme qui le valide ou l'invalide. Et vraiment j'insiste sur le fait que si le programme (a) tourne en environnement limité il existe au moins un programme (b) qui le valide ou l'invalide (même si pour celà le programme doit tourner dans un environnement exponentiellement plus vaste que celui du programme (a))
Une preuve fausse n'a pas beaucoup d'intérêt.
Si, on sait qu'on peut foutre le programme à la poubelle, ou au moins le corriger pour le rendre valide.
Mais dans la plupart des cas, tu ne pourras démontrer ni l'un ni l'autre, et c'est tout le problème.
Oui mais la réponse "on sait pas" => preuve fausse. Merci de revoir votre copie messieurs les programmeurs.
Par état souhaitable, tu veux dire état dont on sait qu'il mêne au bon résultat (et à une terminaison du programme) ? Si c'est le cas, alors la détermination des états souhaitables revient à prouver le programme,
Pas tout à fait, mais c'est vrai que c'est le plus gros du boulot.
un état souhaitable est par exemple : variable d'entrée comprise entre 0 et 1, variable de sortie de type booléen contenant vrai ou faux. Après il faut encore démontrer que la variable de sortie est bien la bonne d'après les specs ie que le code de calcul est juste.
et est impossible dans le cas général par quelque chose de puissance équivalente à une machine de Turing (MT).
Dans le cas général oui.
Prouver qu'un programme termine (sur un jeu de données fixé) n'est qu'une question de temps: il suffit de l'exécuter
Euh non pas du tout. C'est pas parcequ'il s'execute une fois, qu'il le fera forcément la fois d'après même avec le même jeu de données. Tout un tas de question de concurrence et de priorité entrent en jeu. Sans même parler des problèmes liés au threads ou à l'OS sous jacent.
Prouver qu'un programme ne termine pas est une autre paire de manches.
Une fois de plus ca dépend du programme, il y a tout un tas de programmes qui ne terminent pas de façon tout à fait triviale (etats qui bouclent dans un graph par exemple)
Tu as l'air de penser qu'à partir du moment où on choisit un programme en particulier, alors il devient prouvable
A partir du moment ou on a des specs non infinies (ce qui est quand même le cas général) pour ce programme oui. Une fois de plus prouver un programme revient à répondre à deux questions :
- le programme suit-il les specs (oui/non)
- peut on assurer que le programme va se terminer (oui/non)
La réponse à la seconde question peut parfaitement être non. Des programmes comme le jeu de la vie sont de bons exemples. Les specs sont parfaitement respectées, les états des différentes fonctions sont parfaitement connus par contre dans le cas général on ne peut pas savoir si le programme va s'arréter ou non avant d'avoir vu le jeu de données initial. Si on a des specs inifinies (la grille peut avoir n'importe quelle taille, les données initiales peuvent prendre n'importe quelle valeur) on est dans la merde. Par contre si on a une grille de taille limitée par exemple il suffit de rajouter la condition "arrêt si on revient sur un des états précédents" pour être sur que le programme s'arrêtera forcément.
dans les faits il est souvent facile de rajouter des conditions jusqu'à avoir des specs finies vu que l'ordinateur sur lequel tourne le programme n'est pas inifini...
Il n'est pas possible d'écrire un programme validant la terminaison d'un autre programme quelconque
Je n'ai jamais dit celà, par contre il est possible d'écrire un programme validant la terminaison d'un autre programme spécifique dont l'ensemble des données (interne et externe) sont bornées en taille mémoire. En d'autres termes une machine de Turing qui n'a pas une bande infinie...
Démonstration simple, une machine de Turing ne possédant que N états possibles. On détermine que l'etat 0 est arrêt. On a N² transition possible d'un état à un autre (un état pouvant éventuellement boucler sur lui même, amis aucun etat ne peut une fois amener à l'état X et la fois d'après amener à l'état Y). Il y a donc au maximum N état initiaux suivi de (N-1)xN² transition possibles soit N^4-N³ ensembles programmes+données tous parfaitement déterminés. Pour savoir si ils terminent ou non, il suffit de regarder ce quis era fait dans un temps fini (mais plutôt long quand même il faut bien l'admettre)
Si une JVM ne donne pas d'interface vers l'extérieur et ne contient pas de failles, alors tu peux générer du bytecode arbitraire, ça ne te permettra pas de faire quoi que ce soit à l'OS derrière la JVM.
Bon d'accord je change d'exemple
Même en supposant une JVM aussi parfaite que possible, comme c'est une machine virtuelle basée sur la pile, en lui envoyant le bytecode approprié on peut la forcer à dépiler une information (difficile de surveiller la pile parfaitement quand on est obligée d'interagir avec elle pour le moindre fonctionnement). A partir du moment ou on aura pousser la JVM à dépiler à tort, celle ci aura un comportement inconsistant et peut alors générer toutes les erreurs qu'un programme codé en C avec le pied gauche pourrait générer.
Si tu confirmes que dans ce que tu appelles "prouver le code", on peut inclure "prouver que le programme se termine",
La preuve n'est pas forcément vraie. Prouver qu'un programme se termine ne veut pas dire démontrer qu'un programme se termine. Quand on prouve un code on peut prouver qu'il est vrai OU qu'il est faux...
Quand on prouve un programme on cherche à savoir si oui ou non il fait ce qui est marqué sur la fiche de specs. C'est cette information supplémentaire qui permet de faire la preuve.
On ne peut pas écrire un programme qui valide la terminaison ou non de tous les autres programmes car il est impossible de spécifier à priori l'ensemble de toutes les specs de tous les programmes. Par contre sur un programme donné, dont on connait par avance les specs et les états souhaitables il est possible (même programmatiquement) de voir
a) Si on ne rencontre effectivement que des états souhaitables
b) Si on termine le programme.
Avant d'arriver au b) il faut d'abord valider le a) sinon on se retrouve avec un programme dont on ne connait pas les specs et de fait on est bien en peine de démontrer si il va boucler ou non vu que son comportement n'est plus formalisé. Par contre une fois que l'on a le a) et donc un nombre d'état possible limité, prouver le b) n'est qu'une question de temps.
Pas besoin d'étaler ta science,
Je n'étale pas ma science, mais d'un coté tu dis que les langages de haut niveau sont trop complexes et n'apportent rien et de l'autre tu donnes des exemples de langages de plus haut niveau que le C qui apportent des plus en terme de sécurité, de calreté de code ou de prouvabilité. Choisi ton camps camarade. Tout ce que je dis est que du point de vue de l'OS peut importe que ce soit un programme en C ou un programme tournant sur une JVM, les droits seront les mêmes, les erreurs potentielles aussi.
Je te mets au défi d'écrire un programme en Java pur (pas d'appel à du code natif hein)
Je prend ton "pas d'appel à du code natif" comme une interdiction d'utiliser des commandes extérieures à java. Cependant pour aller en dehors de la zone mémoire allouée, il va quand même falloir taper sur des appels systèmes à l'OS.
La façon la plus simple de faire celà est d'aller modifier le bytecode d'une des classe de base. Ca se fait très bien avec javassist par exemple : http://www.csg.is.titech.ac.jp/~chiba/javassist/
Cette bibliothèque java permet de changer à la volée les noms, les méthodes et dans une certaine mesure les types des classes chargées.
Peut-être faudrait-il préciser ce qu'on entend par "prouver", parce que pour moi, même prouver qu'un programme s'arrête, c'est balaise
C'est faire un algorithme capable de vérifier si un programme s'arrête ou non qui est balèze. Prouver qu'un programme s'arrête peut être très simple.
Par exemple le programme composé de la seule instruction exit(0); s'arrête de façon triviale. Pour les programmes plus complexes ca se résoud à coup de théorie des graphs, de validations algorithmiques et/ou de calculabilité.
Certaines méthodes sont plus faciles à prouver que d'autre. L'approche récursive par exemple est très facile à prouver. Prouver un programme revient à regarder l'ensemble des états qu'il peut traverser (éventuellement l'ensemble des états que chacune de ses fonctions peut traverser) et à vérifier pour chaque état ou pour chaque ensemble d'état que l'état suivant est bien valide.
Bah un programme écrit en B peut être prouvé.
Il va fallor donner des exemples de langages de programmation turing complet ET non prouvable. Le B possède des outils et uen sémantique qui facilitent la preuve mathématique, mais à partir du moment ou on a un code turing complet et un compilateur/interpreteur déterministe on peut prouver un code. Le contraire serait inquiétant.
C'est plus une sécurité vis-à-vis d'un plantage "non prévu".
La preuve permet de certifier un comportement, mais ne met pas à l'abri des plantages loin de là. Elle garantie juste que si il n'y a pas d'éléments extérieurs au programme qui viennent le perturber le programme finira et donnera un résultat cohérent (celui ci pouvant bien sur être une remontée d'exception). Or des éléments perturbateur il y en a un paquet : problèmes de droits, réponse incohérente d'un composant (typiquement lors de transactions réseau ou IPC), changement de contexte suite à une interruption dans une opération non atomique, dead-lock sur des ressources extérieures au programme et j'en passe. Quand il s'agit de prouver un système (ie le programme, les programmes qui tournent à coté, l'os sous jacent et le matériel) c'est une autre paire de manche... Et là le B n'aide pas particulièrement.
Pour Java, il y a une couche d'abstraction entre le code généré et le code réellement exécuté, autorisant un certain nombre de vérifications supplémentaire par rapport à un programme natif compilé à partir d'un langage autorisant à peu prêt tout et n'importe quoi comme accès bas niveau
De deux choses l'une, soit tu devellopes pour windows Me/98/95 soit je suis au regret de t'apprendre qu'un programme écrit en Java a exactement les mêmes droits qu'un programme écrit en C. Le langage Java n'apporte rien au niveau limitation d'accès bas niveau par rapport au langage C. On peut par exemple aller écrire (essayer en tout cas) dans un ségement de mémoire qui ne nous appartient pas. Si l'OS est bien foutu il sortira le fusil à pompe et on aura un mort sur la consicence. Le framework java permet de limiter la casse sur les plus grosses erreurs, mais il existe aussi d'excellents frameworks en C avec garbage collector et controle des I/O qui font un super boulot quand il s'agit de hurler à la compilation plutôt qu'à l'execution.
mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charette.
Pour bien comprendre ce qu'apporte un langage comme Lissac par rapport à un langage comme C il faut penser aux non programmeurs. Pour être honnête je en connais pas Lissac, mais l'avantage majeur des langages de haut niveau est de permettre à des non initiés de modifier facilement une partie du programme suivant leur besoin. De même qu'un cube de données bien que plus lourd qu'une base est plus facile à manipuler, il m'a été donné uen fois dans ma vie de coder un logiciel en prog dont les prédicats étaient librement accessibles aux utilisateurs qui disposaient également d'un shell réduit pour appeler les fonctions quia vaient étés codées. Moyennant une formation légère d'une semaine, les utilisateurs pouvaient aussi bien évaluer les faits réels que lancer des simulations en pagaille. La même chose en C ou en Java aurait nécessité le dévellopement complet d'une interface doublée d'un parseur interpreteur ou l'action systématique d'un developpeur à chaque fois qu'un utilisateur aurait voulu changer une règle de calcul ou une relation entre objets.
Je confirme. J'ai décroché après l'unité. Si l'unité serait les km/h, je n voix pas ce qu'est la donné ou la valeur. Qui est le "5" de "5 km/h" et dans ce cas que représente l'autre concept ?
L'unité c'est la déclaration exaustive de ce à quoi se rattache notre variable. Dans le cas d'une vitesse par exemple ca ne serait pas simplement "km/h" mais "km/h rattaché à tel objet calculé à tel moment".
La donnée c'est le 5 dans ton exemple. C'est la partie la plus facile du trio.
La valeur c'est le contexte. Comment a-t-on trouvé la donnée ? A-t-on fait appel à une méthode de type object.getproperty, est-ce une valeur de référence utilisé en comparaison dans un contrat, est-ce un calcul fait à partir d'éléments publics ou privés de l'objet etc. En fait la valeur contient toutes les informations dont le compilateur et/ou programme va avoir besoin pour déterminer dans quel ordre il doit lancer ses évaluations.
Par exemple une voiture qui accèlère sur une autoroute. Dans cette voiture le conducteur controle régulièrement la vitesse pour être sur de ne pas dépasser la limitation, et si c'est le cas il ralenti jusqu'à ce que la vitesse redescende en dessous de la limitation.
Intuitivement le problème est très simple à poser en terme de contrats/etats/variables :
Contrat principal : respecter la limitation de vitesse
- 1ere Condition de réalisation du contrat : la vitesse constatée par le conducteur est inférieure à la vitesse limite
- 2eme condition de réalisation du contrat : le conducteur vérifie la vitesse fréquament.
Etats
- vitesse inférieure à la limite
- vitesse supérieure à la limite
Variables
- limitation de vitesse
- vitesse du véhicule
Le problème est que ce qui est naturel pour l'humain ne l'est pas pour l'ordinateur. Posé comme celà l'ordinateur n'a aucune façon de savoir si c'est parceque la voiture change de vitesse qu'elle respecte la limitation ou si c'est parcequ'elle respecte la limitation qu'elle change la vitesse. L'ordinateur étant idiot on peut supposer qu'il va évaluer le problème à l'envers et tendre vers l'état stable :
Contrat respecté => vitesse inférieure à la limite => accélération et ne plus en bouger.
Si un évènement entrainne un changement de vitesse limite (le conducteur sort de l'autoroute par exemple) l'ordinateur qui voit une variable changer arbitrairement va alors la rechanger arbitrairement ou changer arbitrairement l'autre de façon à garder la première condition valide. Du point de vue de la logique mathématique le problème est parfaitement résolu, par contre le programmeur risque de faire un peu la gueule en voyant le comportement de son programme.
C'est là que la dichotomie valeur/donnée permet de résoudre le problème.
On cherche à comparer deux unités qui sont
"suite de chiffre inscrit sur un panneau concernant le tronçon de route sur lequel roule l'utilisateur" et "vitesse de la voiture telle que constaté par le conducteur quand il regarde à l'instant t"
Les valeurs de ces deux unités sont
"donnée aribitraire fixé par la direction départementale" et "résultat du calcul fonction de la donnée au temps t-1 et de l'accélération du véhicule "
Les données sont (par exemple) 70 et 85
Avec une sémantique adéquate on peut alors faire comprendre au système que la seule action possible sur la vitesse est un changement de l'acceleration du véhicule. De fait l'ordre de résolution est
Etat impacte variable entrainne contrat.
Le problème principal qu'il y a à interfacer un cerveau humain avec un ordinateur est que l'ordinateur est une machine à calculer alors que le cerveau est une machine à reconnaitre (tellement puissante qu'elle peut même par le jeu de description reconnaitre des choses qu'elle n'a jamais rencontré auparavant). Au jour d'aujourd'hui toute la puissance de la machine réside dans sa bétise intégrale : elle n'interprète absolument pas ce qu'on lui donne et fait ce qu'on a demandé même si c'est idiot. C'est surpuissant car 1°) celà garanti un fonctionnement cohérent 2°) celà permet au programmeur (la plupart du temps équipé d'une machine à reconnaitre) de comprendre ce qui se passe exactement en morcelant le déroulement pour trouver les erreurs.
Les gros inconvennients de tes paradigmes est qu'ils imposent une interpretation non triviale de l'intention du programmeur. Aujourd'hui c'est techniquement infaisable et pour le futur je ne suis pas sur que celà soit souhaitable. Il est extrèmement délicat de méler affectation, variables et contrats pour plusieurs raisons.
La première est que l'ordre d'évaluation change tout, par exemple si je commence par valider mes contrats, puis que j'affecte mes états, puis que j'évalue mes variables rien ne me dit qu'à la fin de l'évaluation des variables mes contrats sont encore valide... De plus si j'évalue mes variables puis que je valide mes contrats rien ne me dit non plus qu'une des validation n'a pas modifié une variable qui invalide un contrat précédamment validé etc. Pour finir variable -> etat -> contrat n'a pas forcément le même résultat que contrat -> etat -> variable.
La seconde est que lorsque les variables, contrat et etats s'inter-affectent il est horriblement complexe (en fait impossible si le langage est Turing complet) de valider qu'il n'y a pas de référence circulaire ou de deadlock
Par exemple : [(soleil = visible), (pluie=non), (température > 20°c)] -> {il fait beau} -> {il fait jour et chaud} -> [(soleil = visible), (pluie=non), (température > 20°c)]
Il est nécessaire qu'une personne décide si le contrat affecte l'état, ou si c'est l'état qui valide le contrat ou encore si ce sont les variables qui valide le contrat qui à son tour affecte l'état. La machine ne peut pas prendre cette décision.
Or là on touche le problème de fond, le troisième problème, demandez à un être humain si c'est parcequ'un nombre est négatif qu'on met un signe moins devant ou si c'est parcequ'il y a un signe moins devant qu'on le considère comme négatif et il risque un peu de faire la tête. En fait l'interpretation est décidée en fonction de l'ordre dans lequel arrive les données. -4 est recconu comme valeur négative de quatre et valeur négative de quatre est transcrite comme -4. Pour recalquer ce comportement à un système informatique il faut éclater la notion de variable en trois notions :
- l'unité
- la donnée
- la valeur.
L'unité pourrait être vue comme un méta-ensemble de types, c'est ce qui fixe le cadre de ce dont on est en train de parler. Un bonne exemple d'unité serait "vitesse du sous-marin A exprimée en km/h et évaluée à l'instant t=T+2min et 30 seconde de jeu"
La donnée est le contenu de l'unité, c'est à dire soit une information arbitraire saisie ou décidée à l'initialisation, soit le résultat d'une suite de calcul ou d'évènement sur cette donnée.
La valeur est la justification de la donnée en d'autre terme ce qui permet de faire la différence entre un -4 que l'on interprère en nombre quatre en négatif et un nombre quatre en négatif que l'on note -4. bref tout ce qui permet de décider mathématiquement de quoi la valeur est une conséquence et quelles seront ses causes et donc ultimement de décider de l'ordre d'évaluation juste.
Bon il est 5h du mat, je suis pas sur d'avoir résussi à être clair...
Une erreur est un comportement non désiré du programme par rapport à la spécification.
RRRRAAAAAAAHHHHH
Non, les erreurs sont des comportements parfaitement désirés. Ne pas confondre une erreur et un bug. Un comportement non désiré c'est un bug ! Quand on s'attend à un résultat A avec des paramètres valides et que l'on obtient un résultat B ca n'est pas une erreur au sens de la logique du programme, si erreur il y a, elle se trouve dans le code ou (pire) dans le compilateur. Mais il est parfaitement logique, raisonnable et predictible de se prendre un "segmentation fault" dans les gencives quand on déborde de la mémoire allouée par exemple. L'ordinateur fonctionne sur le mode "question stupide, réponse idiote", il faut juste en tenir compte et propager cette logique aux cas que l'ordinateur ne peut pas traiter tout seul ou à ceux qui peuvent poser problèmes plus loin dans le code.
Par exemple si à la question "quel est votre age" on répond "Michel" il faut que le code génère une erreur parceque ca va avoir des répercussions plus tard, de même à la question "quel est votre nom" une réponse de type "42" bien que ne posant pas techniquement de problèmes doit quand même générer si ce n'est une erreur (après tout les pseudos ridicules sont légion sur le grand ternet), au moins un avertissement.
Bref les erreurs sont des comportement parfaitement désirées, et gérer les erreurs consiste simplement à rajouter soi-même des exceptions que l'on pourra traiter dans le but d'éviter de se prendre une exception que l'on ne pourra pas traiter (généralement dès que l'OS ou le CPU s'en mêle c'est foutu)
"vous n'avez rien fait pendant 10 ans et maintenant vous faites un procès....je vous déboute pour non défense de votre brevet quand vous en aviez l'occasion" ?
Un propriétaire a en effet pour devoir de défendre ses brevets de crainte de voir ceux-ci invalidés. Mais ca se contourne très bien.
- On peut prétendre ne pas avoir entendu parler de la violation avant qu'elle ne devienne grand public.
- On peut attenter un procès sur un point particulièrement complexe du brevet. (Monsieur le juge, la partie du brervet sur l'indexation de pistes multiples est juste pour nous defendre en cas ou on attaquerait pour violation d'un autre brevet, par contre les évaluation colorimétrique en flottant 16 bits on ne peut pas laisser passer...)
- On peut prétendre avoir passer du temps à vérifier que l'implémentation du produit attaqué était équivalente à celle couverte par le brevet (et là vu le niveau technique qu'atteint le traitement de signal dans la compression video, ca passe très souvent)
Par contre, concernant les arrondis, l'utilisation de fonction explicite ou des mode de fpu influe sur quoi ? Uniquement la vitesse ? Ou il existe encore des subtilités ?
Ca influe principalement sur trois choses : (en théorie)
- La vitesse (ie le nombre de cycles nécessaires à une opération)
- Le groupement des opérations. Par exemple supposons une opération trigonométrique. En FPU classique disons qu'elle va prendre 6 cycles, par contre pendant toute son execution elle va bloquer le pipeline. Donc c'est maximum 2 opérations (pairage pentium) par block de 6 cycles, et encore à condition de les lancer en même temps. La même interruption vectorisée va prendre 10 cycles mais elle ne bloquera le pipeline que si on change de type d'opération, dans le cas contraire on pourra recharger des valeurs deux cycles plus tard. Donc on aura une réponse au bout de 10 cycles, une seconde au bout de 12, une troisième au bout de 14 etc. Soit un cout degressif qui va tendre vers 2 cycles par opérations (contre trois en FPU classique). Par contre ce type d'opérations est très sensible aux interruptions.
- Les ressources. La FPU classique tend à bouffer quelques registres éventuellement doublés, éventuellement étendus en interne et de la pile. Les opérations vectorielles elles bouffent des regsitres à la pelle, mais ne touchent pas trop à pile (en théorie toujours)
En pratique, la différence entre ce qui devrait se passer en théorie d'après le code machine "en direct de l'assembleur" et se qui se passe réellement au niveau microcode fait que tout celà est de moins en moins vrai. Les processeurs modernes sont capables dans une certaine mesure d'aller piocher dans les regsitres de l'unité d'à coté quand celles-ci (les unités de traitement) ne sont pas tout simplement fusionnées au niveau hard et émulent un comportement ou l'autre en fonction du code machine. (à ce niveau là les processeurs des cartes graphiques sont un vrai bonheur). Bref pour optimiser correctement, il faut la doc complète du processeur (quand elle existe pour le grand public bien sur)
Les modes fast sont souvent des optimisations et des réglages faits au niveau logiciel. Il y a en grosso modo de trois sortes :
- désactivation de certains flags du CPU. (genre la carry sur off, le NAN qui devient une sentinelle et j'en passe)
- réquisition de registres "pas fait pour" dans certains calculs. Ca permet d'avoir plus de registres et donc d'accélerer les calculs, mais certains évènements ne se déclenchent pas lorsqu'il y a des débordements par exemple, ou des nombres qui sont furieusement proches de 0
- réorganisation des opérations dans un ordre qui est plus favorable au processeur (du coup on ne peut plus additionner des fourmis et des éléphants)
Le fast math c'est la soupe du compilo.
Les modes dit rapides sur les processeurs sont souvent des modes qui substituent ou ajoutent aux registres possédants une précision interne plus forte que la précision apparente des registres possédant une précision exacte. Mais on trouve aussi des modes rapides qui font des calculs complètement différents en fonction du mode choisi. C'est le cas par exemple des directives OpenGL de GLHint qui peuvent changer le comportement (et le rendu) du tout au tout en fonction de si on est en GL_NICEST ou en GL_FASTESt
cela n'est génant que pour la detection d'errreur et non pour le fonctionnement nominal
Oui et non. Quand on s'ampute du NAN il vaut mieux savoir ce que l'on fait. car on a plus aucun moyen de savoir si l'on a saturé l'espace de retour (le ou les regsitres qui contiennent le résultat), si l'on a passé des arguments incohérents ou si tout va bien. Bref il faut avoir borné à priori l'intervalle de des paramètres et celui du résultat. Si on décide, par exemple, pour gagner du temps d'utiliser des fonctions logiques (AND, OR etc.) sur des regsitres qui sont supposés être en FPU faut pas venir se plaindre après si les résultats ne veulent pas dire grand chose....
# Il manque juste le principal dasn l'article d'Agoravox.
Posté par Jerome Herman . En réponse au journal Le dollar et l'empire. Évalué à 10.
Les accords de Bretton Wood n'ont pas pour but de placer le dollar comme monnaie étalon, mais ont pour but de permettre aux pays émergeant et à ceux dont la monnaie a été fortement dévalué pendant la guerre de s'appuyer sur la monnaie la plus stable au sortir de la guerre : Le dollar. Grosso-modo ca permet de garantir sa monnaie contre du dollar. Mais rien n'empêche un pays dont l'économie est forte de placer sa monnaie sur des marchés de change et d'obtenir un prix basé sur le système traditionnel d'offre et de demande.
Les pays n'achètent que très rarement du dollar, le plus souvent ils achètent des T-bonds (c'est à dire des bonds du trésor émis par le gouvernement américain). Ces bonds existent à plus ou moins long terme (de 10 à 30 ans) et permettent aux pays de limiter en partie leur inflation. Il existe aussi des Notes (treasury notes) pour la dette à court terme (2 à 5 ans). Les intérêts sont payés tous les six mois, le principal est rendu à échéance du coupon.
Ce qui se faisait avant est que les pays qui possédaient des bonds du trésor utilisaient le versement des intérêts pour racheter d'autres bonds. Notablement la Chine qui se servait de ce système pour maintenir le Yuan à un prix raisonnable (le Yuan n'étant pas présent sur les marchés de change sont prix et défini de facto par la quantité de bonds que possède le pays). Aujourd'hui la Chine possède plus de 30% de la dette à court terme des US.
Seulement il s'est produit un certain nombre de choses qui ont cassé ce système. Tout d'abord un bon nombre de pays "émergeant" qui assuraient leur monnaie fragile sur le dollar ont émergés et n'ont plus besoin de la garantie. De plus les manœuvres de M Bush jr sur le système de retraite ET sur le health care ont rendus les bonds nettement moins intéressants. Ensuite le dollar, pénalisé par l'industrie ralentie des US s'est cassé la figure face aux autres monnaies fortes des marchés de change. De fait il est devenu nettement plus intéressants d'acheter du dollar directement que de chercher à acquérir des bonds. Comme en prime tous les pays ou presque possèdent déjà des bonds, en cas de besoin de dollars, il est plus facile d'attendre leur arrivé à terme ou de revendre les bonds sur les marchés que de se donner la peine d'aller acheter du dollar sur les marchés. Les Etats Unis se sont donc retrouvés dans l'incapacité de financer leur propre dette intérieure. Alan Greenspan en jouant des taux d'intérêt comme un virtuose a réussi à limiter les dégâts pendant près de cinq ans (de 2002 à 2007) mais son départ, un peu forcé, a mis fin au miracle et aujourd'hui le problème des subprimes (hausse des taux automatique sur les emprunts contractés indexés sur les taux d'intérêts ) fait qu'un bon nombre d'américains se retrouve dans une situation précaire.
Au final, ce qui se passe est que tout le monde a du dollar, mais que plus personne n'en veut. Même les pays qui engrangent du pétrodollar par milliards s'empressent de les revendre contre du Yen/Euro dès qu'ils le touchent pour éviter de perdre trop d'argent. ce qui aggrave encore la chute du dollar.
Donc pour "sauver" le dollar, il faudrait non seulement que les États-Unis réussissent à empêcher des marchés de matière première de passer en une autre monnaie que le dollar (et pour les métaux c'est déjà foutu; or ce sont eux qui subissent la plus forte hausse des prix) mais il faudrait aussi qu'ils arrivent à dynamiser leur industrie/baisser leur taux d'intérêts et qu'ils arrivent à convaincre les pays extérieurs de recommencer à acheter du bonds. Déclarer une guerre à un pays de plus (surtout un pays comme l'Iran) serait désastreux à tout point de vue. Tout d'abord parce que même si ça dynamiserait l'industrie interne, le gouvernement est à cours de liquidités il lui faudrait donc émettre en masse des coupons de dette (dont personne ne veut et qui sont déjà responsable d'une crise de l'immobilier à l'heure actuelle), ensuite parce que des pays comme la Chine, la Russie, l'Inde et le Brésil qui sont de gros producteurs pétroliers sont déjà en pourparlers d'ouverture de marchés en Euro et que déclarer la guerre à ses pays est impensable (à moins de vouloir réellement une troisième guerre mondiale, dont les US qui n'ont plus la puissance industrielle qu'ils avaient en 1940 ne peuvent pas franchement se remettre).En plus la Chine et l'Inde possèdent suffisamment de bonds pour inonder les marchés et empêcher toute émission du gouvernement de se faire avec succès. Enfin parce que même si le but visé est atteint (les marchés du pétrole restent en dollars) rien n'empêchera les pays de revendre lesdits dollars contre d'autres monnaies, ce qui ne fera qu'aggraver la situation du dollar faible.
La volonté des US de garder les marchés du pétrole en dollars est purement symbolique, elle permet de minimiser la crise. Tant que le dollar reste une monnaie de référence, on peut essayer de convaincre que la crise n'est que passagère et que l'on ne s'engage pas dans une grande dépression.Si les marchés pétrole s'ouvrent à d'autres monnaies, la confiance des marché de change risque de s'effondrer ce qui achèverait le dollar.
[^] # Re: Je me suis toujours demandé...
Posté par Jerome Herman . En réponse à la dépêche Le serveur XMPP libre ejabberd en version 2.0. Évalué à 2.
En ce qui concerne la config Erlang : il n'y a pas de règles ou de trucs. Ca se configure appli par appli.Par contre la config Ejabberd est un poil plus complexe à maitriser. Les logs sont assez problématiques à comprendre et à mettre en place correctement. Pour le reste je suis contraint de te renvoyer au manuel. il y a des pages et des pages de config. Mais ce n'est pas très compliqué. CF http://www.process-one.net/docs/ejabberd/guide_en.html#htoc9
Après si tu as des questions plus spécifiques, tu peux me joindre par email ou via les messages privés.
[^] # Re: EN 347
Posté par Jerome Herman . En réponse au journal HS plan fringue. Évalué à 4.
La plupart des hydrocarbures sont :
- Corrosifs
- Cancérigènes
- Chargés en métaux lourds (notablement le plomb)
- Solvant des graisses (va avec corrosif, mais ajoute un bonus)
- Neurotoxiques (à cause du plomb d'une part, mais aussi à cause des molécules aromatiques qu'ils contiennent souvent)
Plus deux trois trucs évidents comme, inflammables, toxiques et volatils (bon sur le dernier point, la godasse peut rien pour vous)
A titre d'exemple un homme placé sans protections dans une cuve de pétrole brut est dissout en quelques heures...
Donc pour les gens qui sont sans arrêt exposés à ce genre de produits, la protection est une bonne idée.
[^] # Re: Je me suis toujours demandé...
Posté par Jerome Herman . En réponse à la dépêche Le serveur XMPP libre ejabberd en version 2.0. Évalué à 4.
GNI ???? Tu as mis tes machine virtuelles jabber dans d'autres machines virtuelles ? Et ca marche mieux ?
A mon avis il y a un gros problème avec ta config erlang.
Mon serveur, qui n'est pas un foudre de guerre même si il a 4go de ram encaisse sans broncher près d'un million de demande de connexion par minute (en test labo hein, il y a pas 300 utilisateurs réels sur la bécane). Je pense qu'il pourrait encaisser plus, mais c'est la connexion qui limite.
# Tout va bien.
Posté par Jerome Herman . En réponse au journal Et hop, bientôt le Sonny Bono Act à la française !. Évalué à 3.
Le pauvre, il est mal renseigné. les artistes indépendants restent propriétaires de leurs œuvres dans la majorité des cas. De fait le décompte des 50 ans ne commence qu'à leur mort.
Seuls les artistes qui ont signés des contrats "employés" avec des boites de prods ou des majors voient le décompte commencer dès la sortie du disque, car c'est alors la maison de disque qui devient propriétaire des droits.
Tout va donc bien pour les petits. M McCreevy peut dormir tranquille.
# Assez faicile à installer et pas trop chere
Posté par Jerome Herman . En réponse au journal Carte contrôleur sATA pour carte mère ancienne génération (PCIà. Évalué à 5.
Son gros défaut est d'avoir un bios intégré un peu vampire qui n'aime pas trop quand il y a d'autres contrôleurs SCSI/SATA sur le port PCI. Plus rarement on peut avoir des problèmes avec le contrôleur intégré à la carte mère si celui-ci a des options avancées (Raid logique onboard, couplage de chipset sata en pagaille etc.)
Ce défaut peut être résolu en effaçant pure et simplement le bios de la carte.
Ses avantages sont les suivants :
a) C'est une vraie carte Sata, comprendre qu'elle gère vraiment toute la pile SATA toute seule, ce n'est pas une carte qui fournit un peu de câblage et qui se repose massivement sur le pilote logiciel et le CPU pour traiter les demandes.
b) Elle est très bien reconnue et bien supportée par Linux et BSD.
c) Elle n'est pas trop chère.
d) Si on n'a pas d'autres cartes contrôleurs dans al machine, le bios offre quelques options intéressantes.
En ce qui concerne Silicone Image, ceux basés sur un Sil3112 sont passables, mais un peu vieillot, par contre pour les autres chipsets il faut vérifier qu'il s'agit bien de contrôleurs complet. Pas de cartes qui repassent tout le boulot au CPU.
Finalement, si c'est pour faire du raid, il faut taper dans le haut de gamme direct. Quasiment toutes les cartes SATA en PCI font du raid logiciel via le pilote. Autant activer le raid logiciel avec les outils Linux à ce moment là, on a souvent de meilleures perfs et une consommation CPU moindre...
# Très simple
Posté par Jerome Herman . En réponse au journal [ Un peu HS ] Et vous, vous dites quoi lorsqu'on vous demande ?. Évalué à 5.
Je peux faire un prix pour les amis mais je refuse catégoriquement de bosser sur des XP piratés (remplir le tonneau des danaïdes ca me tente moyen).
Je prévient que pour éliminer un spyware bien accroché (planqué derrière des fichiers invisibles et déclaré comme devant être restauré en cas d'effacement) il faut en moyenne 4 à 5h pour récupérer le PC et le protéger, ainsi que pour faire un peu de pédagogie vis à vis de l'utilisateur.
Sous Linux/BSD je suis nettement moins cher (et gratuit pour les amis).
A noter que la personne qui a payé 250€ pour récupérer ses données est nettement plus sensible quand on lui dit qu'il ne faut pas cliquer sur tout et n'importe quoi ou installer les petits trucs rigolos qui trainent sur internet. Statistiquement la personne qui ne paye pas se reprend un virus/spyware par sa propre faute dans les deux mois...
La plupart des boites et/ou indépendants m'expliquent qu'ils préfèrent payer pour du windows car il y a une multiplicité de supports commerciaux. Alors ma foi, si ils préfèrent payer...
# Sans ordre particulier.
Posté par Jerome Herman . En réponse au journal Quel sont selon vous les meilleurs morceaux de musique classique ?. Évalué à 3.
Beethoven, symphonie n°2 : moins connue que la scandaleuse 9 mais un vrai régal. A prendre dirigé par Karajan avant 1965 ou par FurtWängler si tu trouves.
Mozart Symphonie 41 "Jupiter" dirigée par Seiji Osawa ou Karl Bohm (surtout pas la version de Karajan) : quand Mozart s'ennerve...
[^] # Re: HS adoption par célibataire
Posté par Jerome Herman . En réponse au journal Les adeptes du p2p dépendent de la clémence de leur FAI. Évalué à 1.
Je ne suis pas du tout d'accord, il y a une différence fondamentale entre rencontrer une personne qui a un enfant (et qui dans le meilleur des cas va pouvoir dissimuler cette information quelques semaines) et vire depuis des années avec une personne qui d'un seul coup sans demander votre avis ou presque a un enfant de 2 à 4 ans. Dans un cas l'enfant peut s'interposer dans la relation et l'empêcher d'aboutir, dans l'autre cas on a un facteur qui peut briser une relation de couple durable avec tous les traumas directs et indirects que cela peut causer à l'enfant.
Choisir de vire avec une personne qui a un ou des enfants et se retrouver du jour au lendemain lié à un enfant de façon durable sont deux choses distinctes au niveau psychologique. Je comprend tout à fait la prudence des services sociaux en la matière.
[^] # Re: Plaf
Posté par Jerome Herman . En réponse au journal Vous savez quoi ?. Évalué à 1.
Oui, enfin Solaris prend une approche résolument différente des Unix classiques depuis la version 10. Notamment sous Solaris 10 et OpenSolaris il est assez fortement recommandé de ne pas mettre /usr sur une partition à part justement pour des questions de liens dynamiques. En fait il semblerait que Solaris soit bien décidé à tuer sur ses systèmes toute notion de liens statiques.
[^] # Re: Plaf
Posté par Jerome Herman . En réponse au journal Vous savez quoi ?. Évalué à 5.
Le shell root est parfois la seule arme qu'il reste quand on a un gros problème sur une machine, notament en cas de corruption de disque dur et de problème sur la table de partition.
Ce qui casse le plus les pieds à un admin (et de loin) et de devoir descendre en salle machine, voir de devoir prendre un taxi pour aller jusqu'à la salle machine quand un truc part en vrille. le but est donc d'avoir un système totalement indépendant du reste sur le /. C'est pour celà que l'on a un /root et non un /home/root.
Dans la plupart des Unix, comme dans FreeBSD et OpenBSD l'intégralité du contenu de /sbin et la majorité du contenu de /bin est linké en statique et est aussi light que possible (par exemple pas de dépendance à la libc). Le but du jeu étant de pouvoir travailler et tenter de récupérer des données sur un système dont on est même pas sur qu'il reboote. La solution LiveCD a deux inconvennients : tout d'abord elle necessite un accès physique à la machine (ce qui est lourd) et ensuite elle requiert de devoir redémarrer la machine, ce qui est potentiellement dangereux. Une carte RAID qui envoit message d'alerte sur message d'alerte peut parfaitement décider au reboot que les disques sont inutilisables et les achever ou refuser de les rendre accessible.
Dans ce genre de cas, je suis personellement assez content d'avoir tout un BSD minimaliste et linké statiquement sur ma machine, ce qui me permet de récupérer un maximum de données même si le /usr est mort ou si le /var fait des siennes.
On peut faire une version minimaliste et lié en statique de bash, mais elle sera toujours plus grosse que son équivalent sh/csh et donc plus sensible aux corruptions et ensuite bash a une facheuse tendance à remplacer certaines commandes Unix de base par les siennes propres. La bonne façon d'invoquer bash sur un système à l'agonie est bash --noprofile --norc --noediting --posix. Mais si on fait celà il n'apporte vraiment pas grand chose de plus que csh...
[^] # Re: Plaf
Posté par Jerome Herman . En réponse au journal Vous savez quoi ?. Évalué à 2.
- Télécharger l'ensemble des mises à jour de FreeBSD 6.x à FreeBSD 6.3
- Vérifier la cohérence de la configuration avant la mise à jour
- Valider l'ensemble de la mise à jour du kernel space avec ou non installation et activations des modules kernel et des docs associées.
- Valider l'ensemble de la mise à jour du user space et la mettre en place :
# fetch http://people.freebsd.org/~cperciva/freebsd-update-upgrade.t(...)
Télécharger et vérifier la signature numérique du paquet de mise à jour est hautement recomandé (signature par le responsable sécurité FreeBSD)
# fetch http://people.freebsd.org/~cperciva/freebsd-update-upgrade.t(...)
# gpg --verify freebsd-update-upgrade.tgz.asc freebsd-update-upgrade.tgz
La nouvelle version de freebsd-update peut alors être extraite et lancée comme suit :
# tar -xf freebsd-update-upgrade.tgz
# sh freebsd-update.sh -f freebsd-update.conf -r 6.3-RELEASE upgrade
# sh freebsd-update.sh -f freebsd-update.conf install
Le système doit alors être redémaré pour mettre en place le nouveau kernel
# shutdown -r now
Enfin freebsd-update doit être lancé une dernière fois pour mettre à jour l'espace utilisateur et la machine doit etre redémarrée une fois de plus.
# sh freebsd-update.sh -f freebsd-update.conf install
# shutdown -r now
Mise à jour de ma machine FreeBSD 6.1 en 12mn30sec sans aucun problème. Les fonctionnalités web (Apache et Yaws), base de données (Postgres et MySQL), mail (Postfix, Dovecot, Majordomo, RoudCube), authentification (Cyrus SASL, OpenLDAP, ssh) et le système se portent bien.
Mise à jour faite à distance sur une machine Dedibox.
Je ne saurais en aucun cas être tenu responsable des dégats si un utilisateur frustré par ce poste s'amusait à tenter le même genre de chose sur une distrib Linux....
[^] # Re: Enooorme !
Posté par Jerome Herman . En réponse au journal La Flame War de l'année ?. Évalué à 1.
a) Inutilisables
b) Farcies de logiciels proprios.
Inutilisable dans le sens ou elles ne disposent pas de suivi concret, les logiciels possédants des failles de sécurité mettent des plombes à être mis à jour, les diverses limitations "pro-libres" leurs coupent les ailes et la doccumentation est inexistante dans la plupart des cas et non traduite dans les autres. Pour finir la base utilisateur est tellement faible que trouver une solution à un problème particulier nécessite soit des connaissances très complètes dans le système Linux et la distribution soit de "casser" ou de passer outre le système d'installation et de gestion des paquets de la distrib.
Farcis de logiciels proprios dans le sens ou ces deux distributions incluent en standard plusieurs outils pour lire et créer des PDF (soumis à brevet) ou pour lire et créer des fichiers audios et vidéos suivant des standards dérivés du MPEG-Group. Gnewsense va un peu plus loin en empéchant sa version de Firefox (Burning Dog) de vous rediriger directement vers le site d'Adobe quand il tombe sur du contenu Flash, mais honnêtement ca ne change pas grand chose, et de toute les façons le Firefox de Ututo le fait sans complexe.
Bien entendu les deux distribs lisent courament le système de fichier FAT (soumis à brevet) et GNewsense utilise la version CDDL de cdrecord dont la compatibilité GPL a été plusieurs fois questionnée (pour des raisons au moins aussi stupide que le thread dont nous sommes en train de parler)
Donc OpenBSD inclut des ports non libres : Vrai
Celà peut encourager les utilisateurs à utiliser des logiciels propriétaires : Vrai
C'est pour celà que RMS ne peut pas recommander OpenBSD : Faux, celà ne l'a absolument pas empéché de reccomander des distributions qui incluent, utilisent ou poussent à l'installation de logiciels non libres.
RMS joue le sourd et aveugle (mais pas muet malheureusement) de façon totalement hypocrite sur ce coup là : Vrai.
[^] # Re: C'est trop compliqué !
Posté par Jerome Herman . En réponse au journal Des langages de haut niveau. Évalué à 1.
Ce qui m'ennuie avec cette phrase et qu'elle induit violamment en erreur. Dénombrer exhaustivement puis évaluer tous les états d'un programme n'est pas du tout équivalent avec l'execution d'un programme sur l'ensemble des jeu de données possibles à raison d'un million d'execution par jeu. Dans le second cas rien n'indique que l'on a effectivement couvert tous les états possibles. Un état particulier peut très bien ne se produire que dans certaines conditions très précises.
Par exemple si on cumule des arrondis au delà de la limite du CPU, on peut parfaitement avoir un programme qui calcule juste sur un ordinateur et faux sur celui d'à coté.
De plus il n'est pas question d'executer ici le programme, mais de valider ses etat. Celà se fait le plus souvent de façon totalement extérieure au programme. Enfin il ne s'agit pas de valider le programme pour un seul et unique jeu de données, mais pour un ensemble de données toutes bornées.
Avec la doc du CPU et du compilateur il est souvent à peine plus complexe de valider un état pour X appartenant l'ensemble des entiers 32 bits que pour X = 5
C'est un résultat relativement inutile
Si on ne pouvait prouver que sur un seul jeu de données oui, mais comme on peut prouver sur n'importe quel jeu de données borné à partir du moment ou les variables dans les états sont elles-mêmes bornées c'est très très pratique. Comme aucun ordinateur n'a de mémoire ou de registre infini on peut démontrer au cas par cas sur n'importe quel problème. Il arrive même (approche orthogonale aux types) que l'on prouve vrai un programme qui traduit un algorihtme d'un problème indécidable par ce que l'on sait que l'on va forcément se prendre un Out of Memory ou un NaN avant de rentrer dans les cas problématiques.
Un bonne exemple de prblème indécidable qui n'empêche pas des programmes d'être prouvé est le calcul par éléments finis. Si l'utilisateur du programme sort des etats calculables, le programme lui envoie un joli message d'erreur l'invitant à revoir sa copie. Et on construit des avions parfaitement fiables avec ces trucs là...
Pour conclure de mon côté, je renverrais les lecteurs intéressés, s'il en reste, vers le théorème de Rice pour plus de détails:
Une fois de plus le Theorème de Rice démontre que l'on ne peut pas écrire un unique programme P tel que pour tout programme source SPx on puisse avoir P(SPx) -> le programe se termine ou non ET le programme est conforme aux specs. Il ne dit absolument pas que pour un programme quelconque spécifié il est impossible d'écrire un autre programme qui le valide ou l'invalide. Et vraiment j'insiste sur le fait que si le programme (a) tourne en environnement limité il existe au moins un programme (b) qui le valide ou l'invalide (même si pour celà le programme doit tourner dans un environnement exponentiellement plus vaste que celui du programme (a))
[^] # Re: C'est trop compliqué !
Posté par Jerome Herman . En réponse au journal Des langages de haut niveau. Évalué à 1.
Si, on sait qu'on peut foutre le programme à la poubelle, ou au moins le corriger pour le rendre valide.
Mais dans la plupart des cas, tu ne pourras démontrer ni l'un ni l'autre, et c'est tout le problème.
Oui mais la réponse "on sait pas" => preuve fausse. Merci de revoir votre copie messieurs les programmeurs.
Par état souhaitable, tu veux dire état dont on sait qu'il mêne au bon résultat (et à une terminaison du programme) ? Si c'est le cas, alors la détermination des états souhaitables revient à prouver le programme,
Pas tout à fait, mais c'est vrai que c'est le plus gros du boulot.
un état souhaitable est par exemple : variable d'entrée comprise entre 0 et 1, variable de sortie de type booléen contenant vrai ou faux. Après il faut encore démontrer que la variable de sortie est bien la bonne d'après les specs ie que le code de calcul est juste.
et est impossible dans le cas général par quelque chose de puissance équivalente à une machine de Turing (MT).
Dans le cas général oui.
Prouver qu'un programme termine (sur un jeu de données fixé) n'est qu'une question de temps: il suffit de l'exécuter
Euh non pas du tout. C'est pas parcequ'il s'execute une fois, qu'il le fera forcément la fois d'après même avec le même jeu de données. Tout un tas de question de concurrence et de priorité entrent en jeu. Sans même parler des problèmes liés au threads ou à l'OS sous jacent.
Prouver qu'un programme ne termine pas est une autre paire de manches.
Une fois de plus ca dépend du programme, il y a tout un tas de programmes qui ne terminent pas de façon tout à fait triviale (etats qui bouclent dans un graph par exemple)
Tu as l'air de penser qu'à partir du moment où on choisit un programme en particulier, alors il devient prouvable
A partir du moment ou on a des specs non infinies (ce qui est quand même le cas général) pour ce programme oui. Une fois de plus prouver un programme revient à répondre à deux questions :
- le programme suit-il les specs (oui/non)
- peut on assurer que le programme va se terminer (oui/non)
La réponse à la seconde question peut parfaitement être non. Des programmes comme le jeu de la vie sont de bons exemples. Les specs sont parfaitement respectées, les états des différentes fonctions sont parfaitement connus par contre dans le cas général on ne peut pas savoir si le programme va s'arréter ou non avant d'avoir vu le jeu de données initial. Si on a des specs inifinies (la grille peut avoir n'importe quelle taille, les données initiales peuvent prendre n'importe quelle valeur) on est dans la merde. Par contre si on a une grille de taille limitée par exemple il suffit de rajouter la condition "arrêt si on revient sur un des états précédents" pour être sur que le programme s'arrêtera forcément.
dans les faits il est souvent facile de rajouter des conditions jusqu'à avoir des specs finies vu que l'ordinateur sur lequel tourne le programme n'est pas inifini...
Il n'est pas possible d'écrire un programme validant la terminaison d'un autre programme quelconque
Je n'ai jamais dit celà, par contre il est possible d'écrire un programme validant la terminaison d'un autre programme spécifique dont l'ensemble des données (interne et externe) sont bornées en taille mémoire. En d'autres termes une machine de Turing qui n'a pas une bande infinie...
Démonstration simple, une machine de Turing ne possédant que N états possibles. On détermine que l'etat 0 est arrêt. On a N² transition possible d'un état à un autre (un état pouvant éventuellement boucler sur lui même, amis aucun etat ne peut une fois amener à l'état X et la fois d'après amener à l'état Y). Il y a donc au maximum N état initiaux suivi de (N-1)xN² transition possibles soit N^4-N³ ensembles programmes+données tous parfaitement déterminés. Pour savoir si ils terminent ou non, il suffit de regarder ce quis era fait dans un temps fini (mais plutôt long quand même il faut bien l'admettre)
[^] # Re: C'est trop compliqué !
Posté par Jerome Herman . En réponse au journal Des langages de haut niveau. Évalué à 1.
Bon d'accord je change d'exemple
Même en supposant une JVM aussi parfaite que possible, comme c'est une machine virtuelle basée sur la pile, en lui envoyant le bytecode approprié on peut la forcer à dépiler une information (difficile de surveiller la pile parfaitement quand on est obligée d'interagir avec elle pour le moindre fonctionnement). A partir du moment ou on aura pousser la JVM à dépiler à tort, celle ci aura un comportement inconsistant et peut alors générer toutes les erreurs qu'un programme codé en C avec le pied gauche pourrait générer.
[^] # Re: C'est trop compliqué !
Posté par Jerome Herman . En réponse au journal Des langages de haut niveau. Évalué à 1.
La preuve n'est pas forcément vraie. Prouver qu'un programme se termine ne veut pas dire démontrer qu'un programme se termine. Quand on prouve un code on peut prouver qu'il est vrai OU qu'il est faux...
Quand on prouve un programme on cherche à savoir si oui ou non il fait ce qui est marqué sur la fiche de specs. C'est cette information supplémentaire qui permet de faire la preuve.
On ne peut pas écrire un programme qui valide la terminaison ou non de tous les autres programmes car il est impossible de spécifier à priori l'ensemble de toutes les specs de tous les programmes. Par contre sur un programme donné, dont on connait par avance les specs et les états souhaitables il est possible (même programmatiquement) de voir
a) Si on ne rencontre effectivement que des états souhaitables
b) Si on termine le programme.
Avant d'arriver au b) il faut d'abord valider le a) sinon on se retrouve avec un programme dont on ne connait pas les specs et de fait on est bien en peine de démontrer si il va boucler ou non vu que son comportement n'est plus formalisé. Par contre une fois que l'on a le a) et donc un nombre d'état possible limité, prouver le b) n'est qu'une question de temps.
[^] # Re: C'est trop compliqué !
Posté par Jerome Herman . En réponse au journal Des langages de haut niveau. Évalué à 1.
Je n'étale pas ma science, mais d'un coté tu dis que les langages de haut niveau sont trop complexes et n'apportent rien et de l'autre tu donnes des exemples de langages de plus haut niveau que le C qui apportent des plus en terme de sécurité, de calreté de code ou de prouvabilité. Choisi ton camps camarade. Tout ce que je dis est que du point de vue de l'OS peut importe que ce soit un programme en C ou un programme tournant sur une JVM, les droits seront les mêmes, les erreurs potentielles aussi.
Je te mets au défi d'écrire un programme en Java pur (pas d'appel à du code natif hein)
Je prend ton "pas d'appel à du code natif" comme une interdiction d'utiliser des commandes extérieures à java. Cependant pour aller en dehors de la zone mémoire allouée, il va quand même falloir taper sur des appels systèmes à l'OS.
La façon la plus simple de faire celà est d'aller modifier le bytecode d'une des classe de base. Ca se fait très bien avec javassist par exemple : http://www.csg.is.titech.ac.jp/~chiba/javassist/
Cette bibliothèque java permet de changer à la volée les noms, les méthodes et dans une certaine mesure les types des classes chargées.
Je te laisse jeter un coup d'oeuil à ce qu'il est possible de faire notamment la dernière partie du tutorial :
http://www.csg.is.titech.ac.jp/~chiba/javassist/tutorial/tut(...)
Et ici
http://www.csg.is.titech.ac.jp/~chiba/javassist/tutorial/tut(...)
Section 5.4 on voit comment il est possible de générer une séquence arbitraire de bytecode.
Bref on a tout ce qu'il faut pour envoyer la JVM dans le mur (même si la bibliothèque étant bien faite, ilf aut quand même y aller)
[^] # Re: C'est trop compliqué !
Posté par Jerome Herman . En réponse au journal Des langages de haut niveau. Évalué à 1.
C'est faire un algorithme capable de vérifier si un programme s'arrête ou non qui est balèze. Prouver qu'un programme s'arrête peut être très simple.
Par exemple le programme composé de la seule instruction exit(0); s'arrête de façon triviale. Pour les programmes plus complexes ca se résoud à coup de théorie des graphs, de validations algorithmiques et/ou de calculabilité.
Certaines méthodes sont plus faciles à prouver que d'autre. L'approche récursive par exemple est très facile à prouver. Prouver un programme revient à regarder l'ensemble des états qu'il peut traverser (éventuellement l'ensemble des états que chacune de ses fonctions peut traverser) et à vérifier pour chaque état ou pour chaque ensemble d'état que l'état suivant est bien valide.
[^] # Re: C'est trop compliqué !
Posté par Jerome Herman . En réponse au journal Des langages de haut niveau. Évalué à 1.
Il va fallor donner des exemples de langages de programmation turing complet ET non prouvable. Le B possède des outils et uen sémantique qui facilitent la preuve mathématique, mais à partir du moment ou on a un code turing complet et un compilateur/interpreteur déterministe on peut prouver un code. Le contraire serait inquiétant.
C'est plus une sécurité vis-à-vis d'un plantage "non prévu".
La preuve permet de certifier un comportement, mais ne met pas à l'abri des plantages loin de là. Elle garantie juste que si il n'y a pas d'éléments extérieurs au programme qui viennent le perturber le programme finira et donnera un résultat cohérent (celui ci pouvant bien sur être une remontée d'exception). Or des éléments perturbateur il y en a un paquet : problèmes de droits, réponse incohérente d'un composant (typiquement lors de transactions réseau ou IPC), changement de contexte suite à une interruption dans une opération non atomique, dead-lock sur des ressources extérieures au programme et j'en passe. Quand il s'agit de prouver un système (ie le programme, les programmes qui tournent à coté, l'os sous jacent et le matériel) c'est une autre paire de manche... Et là le B n'aide pas particulièrement.
Pour Java, il y a une couche d'abstraction entre le code généré et le code réellement exécuté, autorisant un certain nombre de vérifications supplémentaire par rapport à un programme natif compilé à partir d'un langage autorisant à peu prêt tout et n'importe quoi comme accès bas niveau
De deux choses l'une, soit tu devellopes pour windows Me/98/95 soit je suis au regret de t'apprendre qu'un programme écrit en Java a exactement les mêmes droits qu'un programme écrit en C. Le langage Java n'apporte rien au niveau limitation d'accès bas niveau par rapport au langage C. On peut par exemple aller écrire (essayer en tout cas) dans un ségement de mémoire qui ne nous appartient pas. Si l'OS est bien foutu il sortira le fusil à pompe et on aura un mort sur la consicence. Le framework java permet de limiter la casse sur les plus grosses erreurs, mais il existe aussi d'excellents frameworks en C avec garbage collector et controle des I/O qui font un super boulot quand il s'agit de hurler à la compilation plutôt qu'à l'execution.
mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charette.
Pour bien comprendre ce qu'apporte un langage comme Lissac par rapport à un langage comme C il faut penser aux non programmeurs. Pour être honnête je en connais pas Lissac, mais l'avantage majeur des langages de haut niveau est de permettre à des non initiés de modifier facilement une partie du programme suivant leur besoin. De même qu'un cube de données bien que plus lourd qu'une base est plus facile à manipuler, il m'a été donné uen fois dans ma vie de coder un logiciel en prog dont les prédicats étaient librement accessibles aux utilisateurs qui disposaient également d'un shell réduit pour appeler les fonctions quia vaient étés codées. Moyennant une formation légère d'une semaine, les utilisateurs pouvaient aussi bien évaluer les faits réels que lancer des simulations en pagaille. La même chose en C ou en Java aurait nécessité le dévellopement complet d'une interface doublée d'un parseur interpreteur ou l'action systématique d'un developpeur à chaque fois qu'un utilisateur aurait voulu changer une règle de calcul ou une relation entre objets.
[^] # Re: Plusieurs problèmes avec tes primitves
Posté par Jerome Herman . En réponse au journal Des langages de haut niveau. Évalué à 2.
L'unité c'est la déclaration exaustive de ce à quoi se rattache notre variable. Dans le cas d'une vitesse par exemple ca ne serait pas simplement "km/h" mais "km/h rattaché à tel objet calculé à tel moment".
La donnée c'est le 5 dans ton exemple. C'est la partie la plus facile du trio.
La valeur c'est le contexte. Comment a-t-on trouvé la donnée ? A-t-on fait appel à une méthode de type object.getproperty, est-ce une valeur de référence utilisé en comparaison dans un contrat, est-ce un calcul fait à partir d'éléments publics ou privés de l'objet etc. En fait la valeur contient toutes les informations dont le compilateur et/ou programme va avoir besoin pour déterminer dans quel ordre il doit lancer ses évaluations.
Par exemple une voiture qui accèlère sur une autoroute. Dans cette voiture le conducteur controle régulièrement la vitesse pour être sur de ne pas dépasser la limitation, et si c'est le cas il ralenti jusqu'à ce que la vitesse redescende en dessous de la limitation.
Intuitivement le problème est très simple à poser en terme de contrats/etats/variables :
Contrat principal : respecter la limitation de vitesse
- 1ere Condition de réalisation du contrat : la vitesse constatée par le conducteur est inférieure à la vitesse limite
- 2eme condition de réalisation du contrat : le conducteur vérifie la vitesse fréquament.
Etats
- vitesse inférieure à la limite
- vitesse supérieure à la limite
Variables
- limitation de vitesse
- vitesse du véhicule
Le problème est que ce qui est naturel pour l'humain ne l'est pas pour l'ordinateur. Posé comme celà l'ordinateur n'a aucune façon de savoir si c'est parceque la voiture change de vitesse qu'elle respecte la limitation ou si c'est parcequ'elle respecte la limitation qu'elle change la vitesse. L'ordinateur étant idiot on peut supposer qu'il va évaluer le problème à l'envers et tendre vers l'état stable :
Contrat respecté => vitesse inférieure à la limite => accélération et ne plus en bouger.
Si un évènement entrainne un changement de vitesse limite (le conducteur sort de l'autoroute par exemple) l'ordinateur qui voit une variable changer arbitrairement va alors la rechanger arbitrairement ou changer arbitrairement l'autre de façon à garder la première condition valide. Du point de vue de la logique mathématique le problème est parfaitement résolu, par contre le programmeur risque de faire un peu la gueule en voyant le comportement de son programme.
C'est là que la dichotomie valeur/donnée permet de résoudre le problème.
On cherche à comparer deux unités qui sont
"suite de chiffre inscrit sur un panneau concernant le tronçon de route sur lequel roule l'utilisateur" et "vitesse de la voiture telle que constaté par le conducteur quand il regarde à l'instant t"
Les valeurs de ces deux unités sont
"donnée aribitraire fixé par la direction départementale" et "résultat du calcul fonction de la donnée au temps t-1 et de l'accélération du véhicule "
Les données sont (par exemple) 70 et 85
Avec une sémantique adéquate on peut alors faire comprendre au système que la seule action possible sur la vitesse est un changement de l'acceleration du véhicule. De fait l'ordre de résolution est
Etat impacte variable entrainne contrat.
13h40 en espérant avoir été plus clair.
# Plusieurs problèmes avec tes primitves
Posté par Jerome Herman . En réponse au journal Des langages de haut niveau. Évalué à 2.
Les gros inconvennients de tes paradigmes est qu'ils imposent une interpretation non triviale de l'intention du programmeur. Aujourd'hui c'est techniquement infaisable et pour le futur je ne suis pas sur que celà soit souhaitable. Il est extrèmement délicat de méler affectation, variables et contrats pour plusieurs raisons.
La première est que l'ordre d'évaluation change tout, par exemple si je commence par valider mes contrats, puis que j'affecte mes états, puis que j'évalue mes variables rien ne me dit qu'à la fin de l'évaluation des variables mes contrats sont encore valide... De plus si j'évalue mes variables puis que je valide mes contrats rien ne me dit non plus qu'une des validation n'a pas modifié une variable qui invalide un contrat précédamment validé etc. Pour finir variable -> etat -> contrat n'a pas forcément le même résultat que contrat -> etat -> variable.
La seconde est que lorsque les variables, contrat et etats s'inter-affectent il est horriblement complexe (en fait impossible si le langage est Turing complet) de valider qu'il n'y a pas de référence circulaire ou de deadlock
Par exemple : [(soleil = visible), (pluie=non), (température > 20°c)] -> {il fait beau} -> {il fait jour et chaud} -> [(soleil = visible), (pluie=non), (température > 20°c)]
Il est nécessaire qu'une personne décide si le contrat affecte l'état, ou si c'est l'état qui valide le contrat ou encore si ce sont les variables qui valide le contrat qui à son tour affecte l'état. La machine ne peut pas prendre cette décision.
Or là on touche le problème de fond, le troisième problème, demandez à un être humain si c'est parcequ'un nombre est négatif qu'on met un signe moins devant ou si c'est parcequ'il y a un signe moins devant qu'on le considère comme négatif et il risque un peu de faire la tête. En fait l'interpretation est décidée en fonction de l'ordre dans lequel arrive les données. -4 est recconu comme valeur négative de quatre et valeur négative de quatre est transcrite comme -4. Pour recalquer ce comportement à un système informatique il faut éclater la notion de variable en trois notions :
- l'unité
- la donnée
- la valeur.
L'unité pourrait être vue comme un méta-ensemble de types, c'est ce qui fixe le cadre de ce dont on est en train de parler. Un bonne exemple d'unité serait "vitesse du sous-marin A exprimée en km/h et évaluée à l'instant t=T+2min et 30 seconde de jeu"
La donnée est le contenu de l'unité, c'est à dire soit une information arbitraire saisie ou décidée à l'initialisation, soit le résultat d'une suite de calcul ou d'évènement sur cette donnée.
La valeur est la justification de la donnée en d'autre terme ce qui permet de faire la différence entre un -4 que l'on interprère en nombre quatre en négatif et un nombre quatre en négatif que l'on note -4. bref tout ce qui permet de décider mathématiquement de quoi la valeur est une conséquence et quelles seront ses causes et donc ultimement de décider de l'ordre d'évaluation juste.
Bon il est 5h du mat, je suis pas sur d'avoir résussi à être clair...
[^] # Re: Sémantiquement
Posté par Jerome Herman . En réponse au journal Qu'est-ce que bien gérer les erreurs dans ses programmes ?. Évalué à 1.
RRRRAAAAAAAHHHHH
Non, les erreurs sont des comportements parfaitement désirés. Ne pas confondre une erreur et un bug. Un comportement non désiré c'est un bug ! Quand on s'attend à un résultat A avec des paramètres valides et que l'on obtient un résultat B ca n'est pas une erreur au sens de la logique du programme, si erreur il y a, elle se trouve dans le code ou (pire) dans le compilateur. Mais il est parfaitement logique, raisonnable et predictible de se prendre un "segmentation fault" dans les gencives quand on déborde de la mémoire allouée par exemple. L'ordinateur fonctionne sur le mode "question stupide, réponse idiote", il faut juste en tenir compte et propager cette logique aux cas que l'ordinateur ne peut pas traiter tout seul ou à ceux qui peuvent poser problèmes plus loin dans le code.
Par exemple si à la question "quel est votre age" on répond "Michel" il faut que le code génère une erreur parceque ca va avoir des répercussions plus tard, de même à la question "quel est votre nom" une réponse de type "42" bien que ne posant pas techniquement de problèmes doit quand même générer si ce n'est une erreur (après tout les pseudos ridicules sont légion sur le grand ternet), au moins un avertissement.
Bref les erreurs sont des comportement parfaitement désirées, et gérer les erreurs consiste simplement à rajouter soi-même des exceptions que l'on pourra traiter dans le but d'éviter de se prendre une exception que l'on ne pourra pas traiter (généralement dès que l'OS ou le CPU s'en mêle c'est foutu)
[^] # Re: Explications : la crainte des brevets dormants par les grosses boite
Posté par Jerome Herman . En réponse au journal Nokia refuse la standardisation d'OGG au sein du W3c. Évalué à 2.
Un propriétaire a en effet pour devoir de défendre ses brevets de crainte de voir ceux-ci invalidés. Mais ca se contourne très bien.
- On peut prétendre ne pas avoir entendu parler de la violation avant qu'elle ne devienne grand public.
- On peut attenter un procès sur un point particulièrement complexe du brevet. (Monsieur le juge, la partie du brervet sur l'indexation de pistes multiples est juste pour nous defendre en cas ou on attaquerait pour violation d'un autre brevet, par contre les évaluation colorimétrique en flottant 16 bits on ne peut pas laisser passer...)
- On peut prétendre avoir passer du temps à vérifier que l'implémentation du produit attaqué était équivalente à celle couverte par le brevet (et là vu le niveau technique qu'atteint le traitement de signal dans la compression video, ca passe très souvent)
[^] # Re: Ecrire du code avec des flottants
Posté par Jerome Herman . En réponse au journal Comment les programmeurs écrivent du code flottant ?. Évalué à 2.
Ca influe principalement sur trois choses : (en théorie)
- La vitesse (ie le nombre de cycles nécessaires à une opération)
- Le groupement des opérations. Par exemple supposons une opération trigonométrique. En FPU classique disons qu'elle va prendre 6 cycles, par contre pendant toute son execution elle va bloquer le pipeline. Donc c'est maximum 2 opérations (pairage pentium) par block de 6 cycles, et encore à condition de les lancer en même temps. La même interruption vectorisée va prendre 10 cycles mais elle ne bloquera le pipeline que si on change de type d'opération, dans le cas contraire on pourra recharger des valeurs deux cycles plus tard. Donc on aura une réponse au bout de 10 cycles, une seconde au bout de 12, une troisième au bout de 14 etc. Soit un cout degressif qui va tendre vers 2 cycles par opérations (contre trois en FPU classique). Par contre ce type d'opérations est très sensible aux interruptions.
- Les ressources. La FPU classique tend à bouffer quelques registres éventuellement doublés, éventuellement étendus en interne et de la pile. Les opérations vectorielles elles bouffent des regsitres à la pelle, mais ne touchent pas trop à pile (en théorie toujours)
En pratique, la différence entre ce qui devrait se passer en théorie d'après le code machine "en direct de l'assembleur" et se qui se passe réellement au niveau microcode fait que tout celà est de moins en moins vrai. Les processeurs modernes sont capables dans une certaine mesure d'aller piocher dans les regsitres de l'unité d'à coté quand celles-ci (les unités de traitement) ne sont pas tout simplement fusionnées au niveau hard et émulent un comportement ou l'autre en fonction du code machine. (à ce niveau là les processeurs des cartes graphiques sont un vrai bonheur). Bref pour optimiser correctement, il faut la doc complète du processeur (quand elle existe pour le grand public bien sur)
Les modes fast sont souvent des optimisations et des réglages faits au niveau logiciel. Il y a en grosso modo de trois sortes :
- désactivation de certains flags du CPU. (genre la carry sur off, le NAN qui devient une sentinelle et j'en passe)
- réquisition de registres "pas fait pour" dans certains calculs. Ca permet d'avoir plus de registres et donc d'accélerer les calculs, mais certains évènements ne se déclenchent pas lorsqu'il y a des débordements par exemple, ou des nombres qui sont furieusement proches de 0
- réorganisation des opérations dans un ordre qui est plus favorable au processeur (du coup on ne peut plus additionner des fourmis et des éléphants)
Le fast math c'est la soupe du compilo.
Les modes dit rapides sur les processeurs sont souvent des modes qui substituent ou ajoutent aux registres possédants une précision interne plus forte que la précision apparente des registres possédant une précision exacte. Mais on trouve aussi des modes rapides qui font des calculs complètement différents en fonction du mode choisi. C'est le cas par exemple des directives OpenGL de GLHint qui peuvent changer le comportement (et le rendu) du tout au tout en fonction de si on est en GL_NICEST ou en GL_FASTESt
cela n'est génant que pour la detection d'errreur et non pour le fonctionnement nominal
Oui et non. Quand on s'ampute du NAN il vaut mieux savoir ce que l'on fait. car on a plus aucun moyen de savoir si l'on a saturé l'espace de retour (le ou les regsitres qui contiennent le résultat), si l'on a passé des arguments incohérents ou si tout va bien. Bref il faut avoir borné à priori l'intervalle de des paramètres et celui du résultat. Si on décide, par exemple, pour gagner du temps d'utiliser des fonctions logiques (AND, OR etc.) sur des regsitres qui sont supposés être en FPU faut pas venir se plaindre après si les résultats ne veulent pas dire grand chose....