ymorin a écrit 499 commentaires

Quand une ressource est partagée, 99,9% du temps, il n'y a pas de contention sur cette ressource

1/ je souhaiterai savoir d'où tu tire cette information

La probabilité est liée à plusieurs facteurs (je ne connais pas l'équation, cependant) :

• la taille de la ressource critique, et donc le nombre d'instructions pour la lier et la modifier, et donc le temps CPU passé en section critique --> t_crit
• le nombre d'instructions exécutés par chaque processus en dehors de la section critique, et donc le temps CPU plus le temps d'éviction (processus qui n'est pas élu pour tourner sur le CPU) passé en dehors de la section critique --> t_triv
• le nombre de processus qui veulent accéder à la ressource critique --> nb_procs
• le nombre de CPU utilisables --> nb_cpu

La probabilité évolue ainsi (à mon avis) :

• augmente avec t_crit
• augmente avec nb_procs
• augmente avec nb_cpu
• diminue avec t_triv

Dans la plupart des cas, le critère le plus important est t_triv, donc la probabilité de contention est faible, très faible. Par exemple pour deux processus qui exécutent l'un 100k et l'autre 50k instructions hors section critique, et partagent une section critique de 20 instructions, et qui tournent en permanence (toujours élus, sur deux processeurs) :

Pcrit(x) : probabilité que le processus x ne soit pas dans sa section critique.
Pcritsys : probabilité qu'aucun processus du système ne soit dans leur section critique.

Pcrit(0) = 1 - (20/100000) = 0.9998 = 99.98%
Pcrit(1) = 1 - (20/50000) = 0.9996 = 99.96%
Pcritsys = Pcrit(0) * Pcrit(1) ~= 0.9994 = 99.94% (arrondi par défaut)

50k instructions, ce n'est déjà pas beaucoup, quand tu vois le nombre d'instructions exécutées pour afficher une fenêtre à l'écran, par exemple.

Et les systèmes dans lesquels un très grand nombre de processus (>10) se battent pour la même ressource critique, est assez faible.

Alors oui, 99.9% est un nombre tiré de mon chapeau. C'est peut-être plus, peut-être moins ; mais assez proche de la réalité. Dans la plupart des cas, ça ne doit pas descendre beaucoup en dessous de 99%.

Hop,
Moi.

loi de jim ready ?

https://linuxfr.org/news/elc-e-2010-un-compte-rendu-libre%C2%A0#14
http://elinux.org/images/5/5c/Deflate-virtualization.pdf

Hop,
Moi.

Alors, qu'un développeur ait en charge la décision d´où mettre les verrous, c'est une aberration.

Ça devrait être fait lors de la phase de conception. Cette phase est trés souvent "oubliée", pour passer directement de l'architecture au développement. C'est stupide.

Et, comme tu le dis, Les développements logiciels se font en temps limité. Certes. Mais bruler les étapes ne permet pas de gagner en robustesse (aka fiabilité), ni même en performances. Au final, comme la phase de conception n'a pas eu lieu, le développement se termine par la mise en place de méchantes verrues dans tous les coins pour ajouter les dernières fonctionalités, corriger les derniers bugs, prendre un raccourci car c'est trop lent, etc… Tout cela au détriment de la maintenance.

Certes, le problème des verrous n'est qu'une partie du problème. Mais à la base, laisser au développeur la responsabilité de décider où mettre des verrous, c'est absurde.

Quand je parle de programmeur, je ne parle pas de développeur. Le programmeur (de mon point de vue, du moins), c'est une personne qui intervient plus en amont, dès la conception, et aussi dans le développement au besoin.

Ensuite, dire qu'un programmeur qui ne maîtrise pas les verrous est un mauvais programmeur, c'est également stupide.

Je n'ai pas dit maîtrise, j'ai dit compréhension. Et si ; un programmeur qui ne comprend pas le principe et le fonctionnement des verrous, c'est un mauvais programmeur. Valable aussi pour le développeur.

Hop,
Moi.

Ce n'est pas une couche d'abstraction supplémentaire.

Oui, je sais. On passe de trois couches avec quatre transferts (kernel -> serveur X -> client X -> server X -> compositeur), à deux couches avec 3 transferts (kernel -> wayland -> client -> wayland). Donc il y a une couche en moins, puisque wayland joue le rôle que le coule {serveur X , compositeur} jouait auparavant. C'est le corollaire à la loi de Ready qui s'applique, en effet :

Pour améliorer les performances, il faut supprimer des couches d'abstraction

À noter cependant, enlever une couche d'abstraction n'améliore pas forcément les performances ( A-implique-B n'est pas équivalent à B-implique-A ! ) ;-)

Hop,
Moi.

C'est une simplification de l'architecture qui est visée pas une augmentation des performances.

Alors, dans ce cas, je préfère la vieille architecture performante, plutôt que la nouvelle simplifiée.

Bon, sûr, à terme, la simplification vas potentiellement amener une amélioration des performances, vu qu'il y aura moins de couches à traverser…

Seconde loi de Jim READY:

Aucune couche d'abstraction supplémentaire ne permettra d'exécuter le logiciel plus rapidement.

Hop,
Moi.

Bien que la simplicité… il faut bien que le programmeur indique les bornes de la transaction.

La différence fondamentale :

• verrous : approche pessimiste : quelqu'un va venir me faire chier pendant que je bosse, donc je protège
• transaction : approche optimiste : si quelqu'un est venu m'emmerder, pas grave, je vais refaire après

Quand une ressource est partagée, 99,9% du temps, il n'y a pas de contention sur cette ressource. L'approche par verrou est pénalisante, car elle protège tout le temps, ce qui est assez coûteux en terme de performances : instruction atomique test-and-set, invalidation des caches de tous les processeurs, etc… Ce sont tous les accès à la ressource qui payent ce prix.

A contrario, l'approche par transaction a moins d'impact au global, car seuls les accès avec contentions payent le prix d'un rollback et d'une nouvelle transaction. Certes, c'est plus cher unitairement qu'un verrou, mais ça arrive beaucoup, beaucoup moins souvent.

Du moins, c'est l'idée.

Hop,
Moi.

la simplicité d'utilisation pour le programmeur

Mauvais programmeur, changer programmeur.

Bein, oui, quoi. Si vous vous faites opérer par un chirurgien qui ne sait pas poser un clamp, mais qu'à la place il vous dit qu'il a plein de poches de sang au cas où, ça vous rassure ? Pas moi.

La mémoire transactionnelle, dans le principe, c'est bien. Je suis même plutôt impatient de pouvoir faire mu-muse avec. Mais il ne faut pas présenter ça comme un palliatif à un mauvais niveaux des programmeurs. Et pour avoir fait de gros systèmes embarqués critiques, la compréhension des verrous fait partie des connaissances de base attendues d'un programmeur.

Hop,
Moi.

être 100% libre ça n'existe pas

Ah oui ? Et RMS alors ?

Et Max, aussi. Il est libre, Max !

Hop,
Moi -> []

J'ai lu :

Open-Pub everything

Et la je me suis dit : "chouette, c'est open-bar sur toutes les boissons !"

Hop,
Moi ~~> []

En quoi ces raisons ne s'appliquent-elles pas pour RSA ?

En fait, avoir la crypto dans le noyau permet d'utiliser les "coffres forts numériques", tels que EVM. Ça vas pour RSA comme pour tout autre algo de chiffrement.

Avec de tels coffres forts, il n'est pas possible d'avoir la valeur de la clé, qui est stockée dans une mémoire inaccessible. Le seul moyen de chiffrer et déchiffrer, c'est d'envoyer un blob dans le module de chiffrement, de lui demander de chiffrer ou déchiffrer, et de récupérer le résultat.

Bien entendu, il n'est pas possible de faire ça depuis l'espace utilisateur, car dialoguer avec le module de chiffrement se fait souvent par des accès restreints (eg. instructions disponibles seulement en ring 0 sur x86, ou mémoire non mappable dans l'adresse d'un processus mais disponible pour le noyau, etc…)

De plus, pour éviter que différents utilisateurs du module ne se "marche dessus", il faut sérialiser les accès. Ça se fait très bien dans un driver, pas en espace utilisateur (non, les sémaphores n'aident pas, par exemple s'il y deux implémentations dans deux programmes ou librairies différents).

Bon, c'est une vue un peu simplifiée, mais c'est grosso-modo la raison de le faire en mode noyau. Le principe vaut aussi pour les algos de hachage, comme sha1 & Co. qui peuvent être accélérés de cette manière (sauf si ce sont des instruction et pas un module matériel, auquel cas la restriction ne s'applique pas, ces instructions n'étant pas protégées).

Hop,
Moi.

quelqu'un a testé avec ce nouveau noyau le driver rtl8192cu […] ?

Le rtl8192cu n'est pas dans staging, mais bien dans les drivers officiels, comme sous-pilote du rtlwifi :

drivers/net/wireless/rtlwifi/rtl8192cu

Le pilote qui est dans staging est le pilote pour le rtl8192u.

J'ai un rtl8192cu et un rtl8192ce à la maison. Je vais les tester ce soir. Ils ne fonctionnaient pas avec le dernier 3.2, et vu les logs du 3.3, j'ai peu d'espoir…

Je vais aussi regarder le rtl8192u pour voir si il peut remplacer le rtl8192cu, ou si c'est un autre chip incompatible.

Hop,
Moi.

J'avais personnellement beaucoup cherché un tel paquet[…]. Merci :-)

Avec plaisir ! :-)

Es-tu le "kpet" que je connais dans la vraie vie ? ;-)

Hop,
Moi.

Trouvant ce journal très intéressant je me suis permis de l'envoyer en modération pour qu'il puisse paraitre en tant que dépêche.

De mon point de vue, ça ne valait pas une dépêche. Ce n'est qu'un tout petit bout d'autotools qui encapsule le kconfig du noyau, il n'y avait pas vraiment de quoi s'emballer, à mon avis.

Mais lire que des gens ( surtout patrick_g ! ) ont trouvé le journal intéressant, bein, c'est pas rien ! ;-)

Merci !

Et sinon : s/paraitre/paraître/;  ;-]

Hop,
Moi.

apt-cache show icedove

J'utilise plutôt apt-cache policy pour avoir la liste des versions, qui pour icedove sur stable me sort :

icedove:
  Installed: (none)
  Candidate: 3.0.11-1+squeeze7
  Version table:
     3.0.11-1+squeeze7 0
        500 http://security.debian.org/ squeeze/updates/main amd64 Packages
     3.0.11-1+squeeze6 0
        500 http://ftp.fr.debian.org/debian/ squeeze/main amd64 Packages

Je trouve ça très facile à lire pour savoir quelle version est installée, quelle version serait installée si je met à jour, dans quel dépôt cette version se trouve, quelles sont toutes les versions disponibles, et dans quels dépôts elles se trouvent.

Hop,
Moi.

Si c'est pour présenter un diaporama (aka slides), j'utilise le module libreoffice presenter-screen.

Sur le vidéo projecteur, la diapo courante est en plein écran. Sur l'écran du portable, j'ai :

• la diapo en cours en ~1/4 d'écran, à gauche en haut ;
• la diapo suivante en ~1/6 d'écran, à gauche en bas ;
• mes notes en 1/2 écran pleine hauteur, à droite ;
• le timing et quelques actions dans une petite barre, au milieu en bas.

Les gros avantages que j'y trouve :

• je fais toujours face à mon public, c'est tellement mieux ;
• j'ai toujours un rappel sous les yeux de ce que je présente ;
• j'ai un pense-bête-anti-sèche à l'écran (je me limite à quelques mots-clé, voire des points hyper-critiques à ne pas oublier ou à rabâcher pour être sûr que le message passe).

Sinon, je ne vois pas. Il reste la duplication (aka clone) d'écran : les deux écrans présentent le même contenu, comme ça tu vois exactement la même chose ( et aussi bien ! ).

Hop,
Moi.

Sans passer par le site de ta banque ?

Je voulais dire : sans lancer mon butineur et me farcir leur site ouaib moisi…

Hop,
Moi.

Ben oui, quoi.

Mes docs ne sont pas hypers complexes, donc je me "contente" de faire du asciidoc.

Pour la publication en ligne, je fais du asciidoc-like dans dokuwiki. D'ailleurs, je vais peut-être me faire un backend asciidoc->dokuwiki un de ces jours…

Hop,
Moi.

La pi day c'est complétement commercial.

Mais moins que la pi hour…

Hop,
Moi --> []

Cela veut-il dire que je vais pouvoir faire mes transactions bancaires en ligne, sans passer par le site de ma banque?

Par exemple, dans mon gestionnaire de compte, qui utilise cette librairie, je fais un virement de compte-à-compte, et ce virement est propagé pour de vrai vers mes vrais comptes ? Même pour des comptes tiers ?

Ce qui m'inquiète sur ce point, c'est que le site officiel de EBICS ne parle que de clients professionnels (corporate customers), ce qui semble exclure toute utilisation à la maison. Plus de précisions sur ce point ?

Standard ouvert, certes. Mais s'il faut taxer (cher, j'imagine) pour avoir sa clé et son certificat acceptés par la banque… Pas glop, pas glop… :-/

Hop,
Moi.

Excusez moi si si j'ai posté dans le mauvais endroit

Non, c'est bien ! Mais comme nous lecteurs trouvons ton post intéressant, nous te suggérons de lui donner plus de visibilité en en faisant un journal, voire même une dépêche.

• Pourquoi un journal ?

  • plus de visibilité
  • donc plus de personnes intéressées liront le journal
  • donc plus tu as de chances d'avoir de nouveaux contributeurs (tests et code)

• Pourquoi une dépêche ?

  • il y a peu d'info aujourd'hui sur ce domaine
  • l'information est vraiment intéressante
  • encore plus de visibilité qu'un journal, car une dépêche est en page d'accueil)
  • et donc encore plus de contributeurs potentiels

Mais de mon point de vue, une dépêche, pourvu qu'elle soit un peu plus fournie que l'entrée de forum, est pertinente car les informations disponibles dans ce domaine sont rares, et donc ton projet mérite d'être mis en avant. Même si je ne suis pas personnellement directement intéressé par le sujet, il mérite vraiment une dépêche.

Hop,
Moi.

on ne peut pas lui en vouloir il a créé son compte ce matin pour nous parler de son projet

Oui, et avoir un retour qui suggère de promouvoir l'entée de forum en journal, voire en dépêche, c'est un retour positif.

Et j'aimerais moi aussi avoir un peu plus d'infos, de contextes et d'explications sur EBICS et les écueils rencontrés lors de son implémentation. Une dépêche serait la bienvenue, en effet !

Merci pour cette info, en tout cas !

Hop,
Moi.

un modem ethernet ou box est une passerelle qui a une un adresse publique internet en ipv4 ou ipv6 ou les deux et une adresse sur le réseau local privé,l'adresse de la passerelle internet

En IPv6, ce n'est pas une adresse publique que la passerelle a, mais une plage (souvent un /64, parfois un /48). En IPv4, c'est une seule adresse.

comment par ipv6 les adresses lan privées peuvent elles être connues du réseau publique sans utiliser un service internet pour les lister où se trouve la différence?

Dans le cas d'IPv4, la passerelle fait du PAT/NAT pour quye les machines du LAN puisse accéder à Internet. On apelle cela du masquerading, car la passerelle masque les requêtes du LAN en faisant croire qu'elles émanent de la passerelle. Par exemple :

1. Le PC du LAN fait une requête sur google.com port 80, et demande la réponse sur sa propre IP, 192.168.1.2, port 45678
2. Sa table de routage indique qu'il doit faire transiter la connection par sa passerelle, 192.168.1.1
3. La passerelle reçoit le paquet et le route vers google.com. Au passage, la passerelle change l'adresse de réponse par sa propre adresse public 1.2.3.4 (exemple) et sur le port 98765 ; elle mémorise cette translation d'adresse et de port : 1.2.3.4:98765 --> 192.168.1.2:45678.
4. Ensuite elle route le paquet normalement, qui part vers google.com
5. gogole.com reçoit la requête, et répond à 1.2.3.4:98765
6. La passerelle reçoit un paquet sur son adresse publique, port 98765 ; elle inspecte sa table de translation, et en déduit que le PC du LAN est à l'origine de a requête. Donc elle remodifie l'adresse de destination en 192.168.1.2:45678
7. Elle route ensuite le paquet, qui part vers le PC du LAN qui reçoit la réponse tant attendue.

Et ainsi de suite. Ce qui permet à plusieurs machines du LAN de contacter des machines sur Internet. L'effet de bord, c'est que les paquets entrants sur l'IP publique de la passerelle ne peuvent jamais être routée vers une machine du LAN, sans que celle-ci soit préalablement à l'origine de la connection (Cf. la séquence TCP SYN/SYN_ACK/ACK) [0]. Ce qui fait office de pare-feu.

[0] Sauf à configurer la passerelle pour faire du port-forwarding, mais à ce moment là, chaque port ne peut être à destination que d'une seule machine du LAN. Impossible de forwarder un même port vers deux machines ; ex: pas possible de contacter le port 22 de deux machines du LAN en se connectant au port 22 de la passerelle, il faut utiliser deux ports (eg. 22 pour la première machine, 23 pour la seconde). Et dans ce cas, il n'est plus possible de contacter la passerelle sur ce port, puisqu'il est à destination d'une machine du LAN.

---

Pour IPv6, la plage d'adresse fournie par le FAI peut être redistribuée dans le LAN. Dans ce cas, il n'y a plus besoin de faire du PAT/NAT, puisque toutes les machines du LAN ont une IPv6 publique. Donc la passerelle peut alors jouer le rôle d'un vrai routeur.

L'effet de bord, c'est que le pare-feu implicite dû au PAT/NAT disparait. La solution simpliste serait de mettre un pare-feu sur chaque machine du LAN. Il est aussi envisageable (et c'est ce qui va se passer!) que la passerelle se intègre un vrai pare-feu.

Bien sûr, il est aussi possible de servir une plage d'adresses IPv6 privées dans le LAN, et à ce moment là les machines du LAN ne sont pas plus joignables qu'en IPv4. Mais au contraire d'IPv4, tu peux faire du simple NAT (translation d'adresse) sans faire de PAT (translation de port) : tu peux avoir une correspondance 1:1 entre les adresses privées et les adresses publiques. Tant que tu ne fais pas de NAT, les machines du LAN seront invisibles d'Internet. Ce qui n'est bien sûr pas le but d'IPv6, au contraire.

Hop,
Moi.

Moi, en tant que mec et hétérosexuel, j'en ai rien à fiche que les nanas mettent des photos de beau mecs en fonds d'écran…

Le calendrier avec les Dieux du stade, personne ne s'offusque. Et pourtant, y sont représentés de beaux mecs au corps bien huilé brillant sous les projecteurs, prenant des poses explicites et aguichantes. On pourrait en déduire que la reprśentation artistique des femmes, c'est sexistes, mais pas celles des hommes ? Soyons un peu cohérents…

Et donc, si tu veux faire venir des femmes sur DLFP, je t'en prie, poste de belles photos de beaux mecs. Je ne viendrais pas me plaindre de ton sexisme (ou de celui de quelqu'un d'autre).

Hop,
Moi, qui tente un coup de poker, là ; et trolldi, c'est bientôt! ;-]

l'outil Fuzzy Fingerprint génère des hashs avec énormément de différence

J'ai un pote qui a soutenu sa thèse de doctorat sur un sujet connexe (Contributions à la sécurité des réseaux dynamiques auto-configurables : application aux réseaux domestiques).

Le but est de présenter à l'utilisateur une représentation visuelle d'un très grand nombre, de façon que les images soient toujours très différenciantes.

Chaque nombre en entrée sert de graine (seed) pour générer un Random Art.

L'identification en est simplifiée : il est largement plus simple de comparer deux images et dire si elles sont ressemblantes, plutôt qu'une suite de caractères hexa. Sachant que deux séquences différentes produiront des images visuellement très différentes, donc dans ce cas "ressemblantes pour un œil humain" est équivalent à "identiques". Si les images ne sont pas identiques, elles ne seront pas visuellement similaires : jamais les mêmes formes, jamais les mêmes couleurs…

La contre-partie, c'est que ça peut poser problèmes pour les déficients visuels (daltoniens, etc…). Dans ce cas, d'autres solutions peuvent être mises en œuvre : empreinte acoustique…

Et je suis d'accord, gpg n'est pas simple à utiliser (et c'est pas faute de faire des efforts et d'être (un peu) de la partie… :-/

Hop,
Moi.

• Rennes : 200 personnes (AFP) ou 60 (Ouest-France). « Les Jeunes Écologistes manifestent contre le traité ACTA »

M'enfin, il n'y avait pas que les jeunes écolos. Il y avait, à peu près, autant de non-affiliés, qui avaient pour certains répondus à l'appel d'Anonymous, pour d'autres celui de LQDN, etc...

Maintenant, j'en ai une contre Anonymous : passer par Facebook pour organiser une manifestation anti-ACTA, je trouve ça assez cocasse, quand même. On m'a même demandé dans le défilé : Comment tu as su pour la manif', si t'es pas sur Facebook?. Quand même... Mince... :-(

Hop,
Moi.