Heu, c'est moi ou un modèle 1:1 est justement plus adapté à des machines massivement multi processeurs qu'un modèle M:N puisqu'il permet plus de parallélisme.
Le pire de tout c'est le 1:N , dans ce cas là grosso-modo c'est quasiment comme si les threads n'existait pas. Tout se dérouel en userland et totu est rattaché au même processus (donc au même thread kernel, donc au même CPU)
Le 1:1 permet pas mal de parallelisation, mais il a ses limites. L'immense avantage de la gestion 1-on-1 est qu'elle ne nécessite pas du tout de planificateur en userland, il suffit généralement de rajouter quelques signaux au planificateur de processus pour s'en sortir.
Le M:N est très complexe à mettre en oeuvre, il nécessite deux scheduler (un en kernelland et un en userland) et il faut en plus que ces deux planificateur soient très bien coordonés. Cependant, il est celui qui offre le plus de flexibilité : dans un modèle avec un SA (Scheduler Activation) le kernel distribue des processeurs virtuels à tous les processus qui font appels aux threads et peut mettre à jour le nombre de processeurs virtuels attribués dynamiquement. Ca permet de constament adapter les threads à la charge effective des processus. Sous certaines conditions on peut même déplacer un thread d'un processeur à l'autre. Mais bon c'ets clair que vu l'overhead impliqué au niveau système, il vaut mieux avoir du processeur disponible, sinon ca sert pas à grand chose.
pour commencer, je peux me tromper dans ce que je dis, et je suis heureux de pouvoir discuter de ceci.
Apparament cependant tu en te trompais pas et c'est moi qui affabulait. Actuellement il semblerait que la NPTL soit toujours basé sur un modèle 1-on-1 (ie chaque thread utilisateur correspond un thread système, c'est à dire un processus) et non pas M-on-N comme ca avait été promis à une époque lointaine et reculée.
C'est un peu dommage pour les ordinateurs vraiment multiprocesseurs (comprendre 8 et plus) mais c'est vrai que pour le reste du monde ca ne change pas grand chose au niveau des perfs et ca allège considérablement la complexité du code.
Je pars me flageller avec des orties fraiches en penitence....
Et pour ce qui est du gain de performances, je me suis toujours demandé s'il serait si bon si on comparait avec du code optimisé "par profil" (on execute une fois le code qui génère un profil d'execution puis on recompile le code de nouveau en exploitant le profil pour amméliorer les perf).
En théorie si le profil d'execution est bien ciblé alors le code compilé repasse devant la dynamo. Cependant la Dynamo restera toujours plus performante sur les appels de fonctions déjà dans son "cache fragment". En francais : même si un a un profil d'execution très bien ciblé, le programme sera quand même obligé de faire et refaire certains tests dont le résultat peut changer, alors que la dynamo peut determiner que le résultat sera identique sans faire les calculs simpelment en comparant les contextes d'éxecution (ce qui est impossible à faire en dehors de l'exécution).
Oui, euh c'est quand meme la *premiere version* qui supporte le multi-CPU..
Oui et non, C'est la première version ou chaque machine Erlang peut s'appuyer nativement sur plusieurs CPU sans efforts de la part du programmeur. Il a toujorus été extrèmement facile de faire tourner un programme Erlang sur plusieurs CPU voir sur plusieurs machines distinctes en mettant les différents process communicants sur différentes machines. Au final il était tout à fait possible de tirer parti de l'architecture complète (mais il est vrai que celà demandait une certainne finesse programmatique).
Enfin, plus généralement, plus il y a de couches présentes à l'exécution , plus le temps d'exécution tend à s'allonger, non ?
Il tend à s'allonger si on ne fait rien oui. Mais par contre plus on a de couches disponibles plus on va pouvoir faire d'optimisations post-compilation.
En C on ne peut pas faire d'optimisation à posteriori, une fois que le porgramme est lancé, sa partie executable (ie par la partie données) ne bouge pas sauf cas super particuliers et très casse gueule tel que l'assembleur automodifiant ou le self linking dynamique.
A l'inverse les programmes tournant sur une machine virtuelle peuvent s'optimiser tout seul en permanence. Par exemple lorsqu'il passent dans une fonction ils peuvent créer une table de hashage des paramêtres passés et de leur résultats et ainsi répondre instantanément si la fonction est appelé deux fois avec les mêmes paramêtres. De même ils peuvent faire sauter un paquet de tests et donc linéariser le code. Pareillement la machine virtuelle peut conserver une empreinte de la config système et ainsi court-circuiter un paquet d'appels systèmes en n'executant pas le bytecode et en plaçant la réponse directement au bon endroit etc.
En d'autres termes on passe d'un mode de calcul de branchement, éventuellement de prédiction de branchement à un mode de branchement direct.
A l'heure actuelle ces optimisations post-execution ne sont pas encore très rentables par rapport à la complexité qu'elles induisent dans la machine virtuelle, mais elles le deviennent. Sur des protocoles de communications complexes il est certain que les machines virtuelles finiront par battre à plate couture les programmes compilés traditionnels gràce a des meccanisme de prise d'empreinte mémoire et système qui leur permettront d'éviter la grosse majorité des tests.
comment je fais pour compiler et exécuter du code en langages de oufs sur de vieilles machines
Tu attends dix ans. Les vieilles machines auront fait de gros progrès d'ici là.
Si t'utilises gcc, ben il est C ANSI strict et il marche sur tous les Unix, et plein de processeurs non ?
Non. a) Il n'est pas C ANSI strict, il peut se comporter comme C ANSI strict si on lui demande. Sinon il fait aussi du C ISO et si on ignore les warnings dans un cas comme dans l'autre on peut glisser assez loin de la norme.
b) Ce qui marche (plus ou moins bien) sur un paquet d'Unix c'est le trio GCC+Autotools et make+GLibc/Libc . Il existe entre les différents composants un degré de compatibilité assez élevé qui fait que les applications sont raisonnablement portables d'un systeme à l'autre, cependant on est loin de pouvoir prendre un programme Linux x86 pour le compiler sur uen station HP-UX.
La machine virtuelle est une émulation, donc c'est moins rapide
CF mon exemple de la Dynamo, parfois c'est plus rapide car plus flexible et donc optimisable pendant l'éxecution du code.
Sache que sous Linux processus et thread sont pour ainsi dire la meme chose
Ca n'est (et heureusement) plus le cas. Linux est passé en mode NPTL depuis un petit moment, donc on a des vrais threads sous Linux et non juste des processus à moitié forkés.
Personellement ca fait pratiquement deux ans que ma Glibc est en NPTL only (elle ne supporte plus du tout les linux threads) et ca marche très bien (sauf pour MySQL, mais c'est un autre débat).
Maintenant les threads sont des entités dépendantes du processus (ie tous les threads d'un process sont ratachés à l'ID de ce process et le kernel ne voit qu'un seul process) et en plus on a une API standard pour créer toutes sortes de threads, les mutex et les sémaphores qui vont avec.
Vitesse : C gagne car proche du langage machine.
Houlà, de moisn en moins vrai çà. Les processeurs commencent à être suffisament costaud poru que l'on puisse s'éloigner assez fortement du langage machine sans que celà pose de problèmes de perfs. Encore plus fort : sur une machine raisonnablement chargé (ie 50% de load CPU moyen) une machine virtuelle peu battre un programme natif. Par exemple toujours sur les codes clients/serveurs une fois la connexio établie il y a pleins de tests, de branchements et de boucles qui deviennent innutiles. Lors d'une éxecution dans une machine virtuelle on peut faire sauter tous ces ralentissements inutiles (Technique d'optimisation post bytecode par linéarisation) et le gain de performance est loin d'être négligeable. A titre d'éxemple le programme Dynamo qui est une machine virtuelle proche des processeurs alpha (i.e : un alpha virtuel) permet un gain jusqu'à 15% de performance sur des programmes nativement compilés pour alpha quand on l'execute sur un alpha.
Pour faire plus court, certains programmes alpha tournent 15% plus lentement quand ils sont executés directement sur un processeur alpha que quand ils sont executés sur une Dynamo sur un processeur alpha.
Portabilité : C gagne grâce aux différents compilateurs.
Pas tout à fait vrai non plus, tout d'abord parceque même si il y a pas mal de compilatuers, très peu sont C Ansi strict. Ensuite en C l'OS influence souvent beaucoup la programmation (Il suffit de comparer du code win32 avec du code GlibC pour comprendre). De toute les façons si le framework est bien fichu, il est quasiment impossible de battre en portabilité une machine virtuelle qui possède la triple compatibilité API/ABI/Source .
Lisibilité : Erlang gagne car il a des fonctions déjà toutes prêtes.
On peut cependant écrire des choses relativement illisibles en Erlang et utiliser des bibliothèques qui rendent le code très lisible en C. Après c'ets plus une question de méthode et de propreté du codeur.
Ca dépend ? Qui veux-t-on comme gagnant ? Si on veut juste se rassurer sur l'inutilité à apprendre un autre langage que le C je suggère le calcul de décimales de Pi ou des suites de Fibonacci en mono processus - mono utilisateur. Le C devrait plier à peu près tout ce qui passe. Erlang va apparaitre comme lent et gourmand en mémoire.
Par contre si on s'amuse à faire un bête programe qui créé 200 serveurs intersynchronisés (comme par exemple pour un MMORPG) et que l'on connecte dessus quelques dizaines de milliers de clients on risque d'avoir 99% des programmeurs C qui vont avoir vraiment du mal. Alors que les programmeurs Erlang ayant un peu d'expérience devraient s'en sortir tous a peu près convenablement. Alors après reste la question de savoir qui entre le meilleur programmeur C et le meilleur programmeur Erlang du monde remporterait la palme. En toute honnêteté ce serait probablement le meilleur programmeur C du monde, mais le meilleur programmeur Erlang du monde aurait à coup sur un code maintenable par d'autres que le meilleur programmeur Erlang du monde.
Erlang à un très fort overhead (charge initiale), donc lui faire éxecuter des petits programmes en boucle le met forcément en position de faiblesse. Ceci dit il scale (monte en charge) très bien (très très même).
De toutes les façons, le langage Erlang est certes turing complet, mais il est destiné très prioritairement aux applications communicantes (archi point à point, client/serveur, n tiers etc.) de fait le comparer avec un langage aussi généraliste que le C n'a pas grand intéret. On pourrait éventuellement imaginer un bench d'une bibliothèque réseau ou IPC face à Erlang, mais comparer brut de décoffrage C et Erlang revent à la bonne vieille comparaison entre le couteau et la fourchette.
Hier ils étaient presque prêt à libérer complètement les sources de JAVA ( CF : http://linuxfr.org/~jahrynx/21655.html )
Aujourd'hui ils font des Machine a base de PowerPC livrée avec une Ubuntu pré-installé pour le calcul massivement parallelisé
Et demain Johnatan Schwartz fait un disque avec le foetus du deuxième bébé de Britney Spear et place la musique en Creative Commons
A Noter que ca fait des années que Sun fait le coup de "libérer" son archi/son OS/sa techno etc. Et que pour l'instant tout ce qu'on a c'est un morceau de Solaris pour x86 et trois lignes sur les controleurs de disques SCSI des Sun - Fire....
Basically the question you are asking makes little to no sense at all.
There are many questions you should ask yourself, the first one being "were are my users, and how are they managed ?". Are they virtual users managed by your mail server (Postfix, sendmail or wathever), real users created on a specific computer or on a specific domain (basically can you log on a computer using the mail credentials ? ) or is it a groupware thing, with a big LDAP/Kerberos Behemoth behind and an IMAP connector in front ?
Creating the user is quite dependant of this.
The you say you do not want to create the mail box, is it because the IMAP connection is just meant as an access to shared folders ? (and so the user won't recieve mail), is it because you plan on creating the mailboxes later, or you plan on having everyone accessing a same common mailbox (like all member of a staff accessing the staff mailbox), or is it because the mailboxes already exists and you just want to make the IMAP server aware of them.
There are also questions about the authentication method (SASL, Kerberos, IPSec etc. ) wether you already choose a PHP framework to work with or want to code everything yourself (the later will take months) and some niceties on wether or no you plan LDAP or X500 integration (which can be with or without SSO).
Basically, you need to sit down and think about what you are trying to achieve precisely, then you will be able to search the net for answers.
Dans la rue, ya du bruit, beaucoup meme.
Et le bruit, ben ca empeche de profiter de la qualite sonore.
Donc mp3 ou flac dans un train, sur un grand boulevard ou autre, je pense pas que ca fasse une grosse difference.
Détrompe-toi. Plus il y a de bruit environnant, plus la musique est difficile à écouter. Donc dans la rue il est plus fatiguant d'écouter de la musique que dans une pièce cloisonnée. L'oreille a moins de travail à fournir pour reconstituer les "bouts" manquants. Seulement si on est dans la rue ET que la musique est de mauvaise qualité, l'oreille a double boulot
a) séparer le bruit environant du signal percu
b) reconstituer les fréquences et sons manquants du signal perdu à cause de la qualité.
Bref écouter de la musique de mauvaise qualité dans la rue est quelquechose de très pénible. On est obligé pour faciliter la perception de pousser le volume à bloc sinon c'est innécoutable. La différence sur 10 minutes d'écoute en millieu bruyant entre du MP3 192 et du OGG 9,5 (ma qualité de référence) est flagrante même pour un non mélomane. Ecouter un morceau en MP3 que l'on ne connait pas déjà par coeur relève de la gageure.
Bref il est d'autant plus important d'avoir une bonne qualité quand on est dans un millieu bruyant que quand on est dan sun millieu calme. Si vous ne me croyez pas vous n'avez qu'à écouter une heure de FM chez vous dans votre chambre puis écouter une deuxième heure de FM dans la rue.
Façon de parler bien sur. Il a rien dit de méchant. Il faut voir que Theo était auteur de pilotes professionnel avant même de rejoindre NetBSD. Donc parler avec les différentes salles techniques des fabriquants il connait un peu.
En ce qui concerne les drivers crackés et la SAV, franchement s'ils conçoivent du matos mal foutu qui grille à la première fausse instruction c'est un peu de leur faute (je met un CD ultra-techno dans ma chaine, si elle grille c'est la faute au fabricant)
Oui mais les fabriquants pour éviter de dépenser trop de frics dans 50 000 chaine sde montage ils ont une seule chaine et dérrière ils testent. ca tient 200Mhz => top rpoduit. Ca tient 180Mhz => moyen produit. Ca tient 150Mhz => bof rpoduit. Ensuite la différence c'est un ou deux petits bits dans le firmware. Des fois aussi ils se content d'éteindre des fonctionnalités dans la puce grace un quelques bits dans le firmware et un gros morceau dans le driver, des trucs auquel l'utilisateur a pas droit parceque c'ets pas uen carte top produit bien sur, mais aussi des trucs expérimentaux qu'on a quand même laissé dans le tape out mais dont on saity qu'ils marchent pas bien. Alors hop désactivés logiciellement.
Dérrière le driver alternatif il te propose bien sur de mettre la vitesse maximale et d'activer pleins de fonctions expérimentales. Et dans certains cas (souvent chez les mecs qui commencent à bidouiller pour voir) frouf la carte.
OpenBSD est un petit projet, mais la totalité des dévellopeurs qui y participent sont des brutes et ils ont de plus des idées très arrétées sur ce qu'ils veulent faire.
Au final ils ne veulent pour rien au monde perdre la main sur leur projet et ils ne font pas dans le compromis. Hors ca c'est pas très interressant pour les fabriquants.
L'intransigence de Theo est ce qui donne sa force à OpenBSD, masi c'ets aussi ce qui le coupe des sponsors. Autant on est prêt à investir dans un projet en création à conditin d'avoir son mot à dire, autant il est plsu difficile d'investir dans un projet qu'on ne peut absolument pas influencer. Au final pour des groupes comme HP ou IBM donner de l'argent à OpenBSD reviendrait soit à payer un produit (OpenSSH) qui est un produit déjà fini, déjà maintenu et déjà disponible, soit à faire du mécénat sur les futurs produits d'OpenBSD. Mais ca n'est pas vraiment un investissement.
Houlàlà.
C'est presque celà, mais pas du tout. Il ne faut pas oublier que les fabricants ont presque toujours fait du propriétaire
Pas du tout en fait, les matériels (jusqu'en 94-95) étaient fournis avec l'ensemble des specs et souvent le schéma matériel et le schéma logique de la machine. Les 286 IBM, les premières sparc et les premières station DEC étaient même fournie avec la structure des pros en bonus. La mode du propiétaire a été instaurée tout d'abord par adaptec qui a commencé à blinder ses piotes et ses specs SCSI dans tous les sens aux alentours de 95. Derrières les autres boites ont suivi (malheureusement). On a eu droit tout d'abord à uen explosions de dongles et de cables bizaroïdes dans tous les sens et pusi on s'est lentement acheminé vers le proprio tel qu'on le connait maintenant.
leur faire comprendre qu'il n'y a réellement aucun risque à publier leurs spécifications ou alors que le risque est acceptable étant donné la possibilité d'avoir de nouveaux clients
Si seulement, on ne compte malheureusement pas les personnes qui veulent absolument mettre le dernier drivers cracké comme un goret par un hacker de l'autre bout du globe et qui permet de gagner 2% de perfs sur certaines applications. Bon des fois le dit drivers fait partir le matos en fumée, lequel matos se retrouve alors en SAV et va savoir si c'est vraiment un défaut ou si le mec a fait n'importe quoi avec. Bien sur sur le matos "haut de gamme" pour els serverus de grande entreprises le risque est plus réduit que l'ingénieur système en place s'amuse à toucher les paramètres pour voir "ce que ca fait". Mais bon sur le haut de gamme il y a souvent des accords croisés, des partenariats et des NDA dans tous les sens. Donc pas de specs publiques non plus.
Cependant, je n'ai pas l'impression que des efforts diplomatiques ont été fait pour la libération des spécifications des différents matériels, ou du moins ça n'a pas été médiatisé sur les médias du libre.
je me permet de placer ici deux citatiosn de Theo de Raddt :
Hardware donations do not come from vendors who use OpenSSH on parts of their stuff. They come from individuals. The hardware vendors who use OpenSSH on all of their products have given us a total of one laptop since we developed OpenSSH five years ago. And asking them for that laptop took a year. That was IBM.
Trad : Les donnations de matériels ne viennent pas des fournisseurs qui utilisent OpenSSH sur des morceaux de leurs produits. Elles viennent de particuliers. Les fournisseurs de matériel qui utilisent OpenSSH sur tous leurs produits nous ont donné un total de un ordinateur portable depuis que nous avons développés OpenSSH il y a 5 ans. Et il a fallu demander pendant un an. C'était IBM
So the HP guy comes up to me (at the Melbourne conference) and he says, 'If you say nasty things like that to vendors you're not going to get anything'. I said 'no, in eight years of saying nothing, we've got nothing, and I'm going to start saying nasty things, in the hope that some of these vendors will start giving me money so I'll shut up'.
Trad : Alors le mec de HP vient vers moi (a la conférence de Melbourne) et il dit, " si vous dites des choses aussi méchantes que çà aux fournisseurs, vous n'êtes pas prêt d'obtenir quoi que ce soit". J'ai dit "Non, en huit ans sans rien dire, on a rien obtenu, et je vais commencer à dire des choses méchantes dans l'espoir que certains de ces fournisseurs commeceront à me donner de l'argent pour que je la boucle."
En bref la méthode diplomatique a été essayée. Elle a échoué.
Par exemple, ATI se retranche derrière le DMCA pour expliquer qu'ils ne peuvent fournir le code source des pilotes sous peine de donner des informations permettant de désactiver le macrovision sur leurs cartes.
Le vrai problème d'ATI (le coté macrovision étant annecdotique) est un problème de fonctionnalités sur lesquelles ils n'ont pas l'ensemble des droits. A la vitesse à laquelle vont les technos 3D aujourd'hui, même un gros poisson comme ATI ne peut pas se permettre d'avori uen équipe R&D assez importante pour trouver des méthodes pour implémenter toutes les fonctionnalités demandées à une carte graphique de nos jours. Pour combler les lacunes ils font appel à des sociétés extérieures (ils ne peuvent pas tout racheter non plus). Ces sociétés extérieures, ne vendent pas du produit mais du papier, elles n'ont donc non seulement aucun interet à ce que les specs de elur focntions soient révélées, mais elles ont même clairement interet à ce que ca reste le plus secret possible (parceque défendre en tribunal que tel implémentation d'un "shader register combiner" est en fait une copie de leur implémentation à eux c'est pas gagné).
Si on ajoute à celà qu'avec les specs complète d'une carte il tout à fait possible de s'arranger pour qu'un jeu brille sur une carte et soit très lent sur une autre (on ira même jsuqu'à dire que ca a déjà été fait plusieurs fois), on comprend vu la fascination qu'ont les power-gamer pour les benchs alac que les fabriquants de puces n'aient pas vraiment envie de fournir toutes leurs specs.
Bin oui parce que rien ne prouve que pour respecter les standard légaux de télécom il faille une partie binaire.
Ce qui ets encore plus fort, c'est que si j'ai envie de me servir du channel 13 pour faire de l'émission hors batiment (ce qui en France est interdit) Il suffit de dire au binaire que l'on habite au canada ou à singapour.
Donc on appréciera le haut niveau de protection et de forcage des normes offert par les blobs en question.
Il a, je cite, "récolté quelques centaines de dollars pour la FSF et la FSF Latin America, et me suis épargné quelques heures de signatures de badges ennuyeuses".
Quel idiot, si il était passé par un modèle libr epour ces autographes, il aurait eu toute une communeauté pour les signer à sa place. En plus il y aurait probablement eu des versions améliorées de sa signature beaucoup plus rapide à faire.
Ce que c'est que d'être prisonnier d'un modèle payant propriétaire....
Ceci dit, moi je cherche plutôt personnellement l'inverse, utiliser l'annuaire Jabber et supprimer LDAP ;-)
Avec tout le respect que j'ai pour le travail effectué par ton équipe et toi, je pense que tu vas un poil trop loin là. Le jour ou tu envisagera de faire de l'IPC en passant par ejabberd ca sera un signe.
On sera obligé de te soigner à coupde stage de programmation d'access par visual basic, et c'est pas beau à voir.
Il convient tout d'abord de vétir Adèle. Dans la mesure du possible si Henry a le bon gabarit lui passer sa veste. Sinon interpeller Jean Michel le plus naturellement du monde et lui demander sa veste (il devrait être assez interloqué pour s'arréter d'être menaçant). Au cas ou aucun des deux gabarits ne convient il faut alors demander à Jean Michel de faire le tour des bureaux pour trouver une veste/un gilet/un pull qui permettra de cacher que l'on ne saurait voir. Voilà Jean-mi occupé à faire autre chose que nous gueuler dessus.
S'abstenir de tout commentaire sur les filles qui ne portent pas de soutien gorge.
Dans un deuxième temps il convient de s'occuper du fax. Soit la remise en place d'un nouveau rouleau prend quelque seconde et Henry et rompu à cette manipulation et on a un nouveau rouleau à disposition, soit il convient de donner rapidement un petit coup de clef dans le piezzo-buzzer du fax pour le faire taire (généralement il est possible avec un entrainnement minimal de rammener le bruit à un léger sifflement audible amis non agressif ). Si le piezzo buzzer est innaccessibles au clefs de Heny un simpel arrachage de prise peut faire l'affaire.
Troisième étape,
On a actuellement dix à douze minutes de retard il convient à ce moment là
a) de savoir si oui ou non il y a un autre fax dans la boite, si c'est le cas téléphoner à Raymond en lui communiquant le nouveau numéro.
A noter qu'il aurat fallu procéder de cette façon avant de se lancer dans le remplacement du rouleau.
Si il n'y a pas d'autres fax dans les bureaux changer encore uen fois le rouleau de fax
Si il n'y a pas d'autres rouleaux de fax d'avance essayer la combinaison mail + imprimante. Si Raymond n'a pas de mail ou d eversion electronique du papier, appeler "allo course" et lui faire prendre les papiers chez Raymond directement (j'espère que Raymond à au moins une photocopieuse).
Si Jean-mi a eu le temps de réhabiller sa fille et recommence à raler lui demander pourquoi alors qu'un fax papier normal avec mémoire coute moins de 200¤ on se trimbale toujopurs une horreur à rouleau. (C'est bas mais ca soulage).
Poster un grouillot à attendre que les feuilles arrive (devant un des fax ou devant le batiment dans le cas de la solution "allo course") Partir en rendez-vous avec environ 15 minutes de retard.
Si c'est un rendez-vous avec les chefs (plusieurs) tout va bien, les chefs ont souvent au moins 16 minutes de retard, vous avez donc une minute complète pour aller jusqu'à la salle de réunion.
Si le RDV est avec un fournisseur. Lui rappeler gentillement que le client est roi (non pas gentillement en fait.)
Si le RDV est avec un client, apporter les cafés, s'excuser platement. Le chef de la bande (Jean Mi ?) Peut même évoquer le mal qu'il y à bosser avec des passionnés-perfectionnistes (mais pas trop, le client aime que l'on respecte lmes délais).
Débaler le dossier, et faire mine de se rendre compte qu'il manque les douze dernières pages. Henry demande à Jean Mi de lancer la réunion et il part chercher les feuilles manquantes.
a) Si sa colique le reprend il peut ainsi refaire un pause. En profiter pour méditer sur la nécessité qu'a un homme qui fait facilement des coliques d'avoir en permanence sur lui de l'immodium et du charbon actif.
b) Si les pages sont arrivées (il a bien du s'écouler 5 ou 10 minutes) il le sprend et il retourne en réunion
c) si les pages ne sont pas arrivés il donne els indications au grouillot pour les lui apporter le plus vite possible une fois qu'il les aura et repart en réunion.
Il faut ensuite tenir assez longtemps sur les X premières pages du rapport pour que les 12 dernières pages arrivent.
Ca devrait passer normalement. Pas glop, masi il est trop tard pour avoir l'air super pro. Si le projet est bien ficelé et el dossier bien construit pas de problème. Si c'était du pipotron ca casse.
On a perdu "hacker", on vient de perdre "geek", il nous reste quoi ? "nerd" ?
Si on prend l'échelle naturelle de l'évolution poste darwinienne nous avons :
LUSER (en français : utilise à tuer)
PEBKAC (problem exist between keyboard and chair - interface clavier-chaise déficiente)
NOOB
NERD (seule étape facultative de l'évolution - on peut passer de noob à geek directement)
GEEK
WIZARD
GURU
MOTKU (Master of the known universe - place vaquante depuis que Seymour CRAY est décédé - contrairement à ce que prétendent les masses désinformantes pomophiles, Steve Jobs ne sera jamais MOTKU)
On a encore un peu de marge avant de s'être tout fait bouffer.
Sauf qu'on te parle du taux d'imposition des entreprises et pas des salariés.
J'avais bien compris, mais je pense qu'il était bon de rapeller qu'il y avait une partie non négligeable du chiffre d'affaire produit par els salariés français qui ne rentrait pas dans les statistiques.
Je sais que ces chiffres ne sont pas exactement comparables. cependant comme il était demandé le taux d'imposition "global" dans la prise en charge de la "flexsécurité" il fallait à mon sens rapeller que la sécurité de l'employé avait aussi un cout très lourd.
A ce propos, on sait à quel niveau se trouve le taux d'imposition global (pas seulement l'impôt sur le revenu) dans un pays où la flexsécurité est à l'oeuvre comme le Danemark ?
Pour rappel en France l'employé moyen est imposé/taxé à hauteur de 70% de son chiffre d'affaire en moyenne. (Personellement je tourne à près de 75%)
A ce niveau là on est imbattable, et on a pas la "flexsécurité" (sic).
Donc je pense que le niveau d'imposition global du Danemark, ca serait plus une bulle d'oxygène qu'une aggravation.
[^] # Re: ...
Posté par Jerome Herman . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 5.
Le pire de tout c'est le 1:N , dans ce cas là grosso-modo c'est quasiment comme si les threads n'existait pas. Tout se dérouel en userland et totu est rattaché au même processus (donc au même thread kernel, donc au même CPU)
Le 1:1 permet pas mal de parallelisation, mais il a ses limites. L'immense avantage de la gestion 1-on-1 est qu'elle ne nécessite pas du tout de planificateur en userland, il suffit généralement de rajouter quelques signaux au planificateur de processus pour s'en sortir.
Le M:N est très complexe à mettre en oeuvre, il nécessite deux scheduler (un en kernelland et un en userland) et il faut en plus que ces deux planificateur soient très bien coordonés. Cependant, il est celui qui offre le plus de flexibilité : dans un modèle avec un SA (Scheduler Activation) le kernel distribue des processeurs virtuels à tous les processus qui font appels aux threads et peut mettre à jour le nombre de processeurs virtuels attribués dynamiquement. Ca permet de constament adapter les threads à la charge effective des processus. Sous certaines conditions on peut même déplacer un thread d'un processeur à l'autre. Mais bon c'ets clair que vu l'overhead impliqué au niveau système, il vaut mieux avoir du processeur disponible, sinon ca sert pas à grand chose.
Pour plus de détails : http://people.redhat.com/drepper/Scheduler.pdf
[^] # Re: ...
Posté par Jerome Herman . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 5.
Apparament cependant tu en te trompais pas et c'est moi qui affabulait. Actuellement il semblerait que la NPTL soit toujours basé sur un modèle 1-on-1 (ie chaque thread utilisateur correspond un thread système, c'est à dire un processus) et non pas M-on-N comme ca avait été promis à une époque lointaine et reculée.
C'est un peu dommage pour les ordinateurs vraiment multiprocesseurs (comprendre 8 et plus) mais c'est vrai que pour le reste du monde ca ne change pas grand chose au niveau des perfs et ca allège considérablement la complexité du code.
Je pars me flageller avec des orties fraiches en penitence....
[^] # Re: ...
Posté par Jerome Herman . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 3.
En théorie si le profil d'execution est bien ciblé alors le code compilé repasse devant la dynamo. Cependant la Dynamo restera toujours plus performante sur les appels de fonctions déjà dans son "cache fragment". En francais : même si un a un profil d'execution très bien ciblé, le programme sera quand même obligé de faire et refaire certains tests dont le résultat peut changer, alors que la dynamo peut determiner que le résultat sera identique sans faire les calculs simpelment en comparant les contextes d'éxecution (ce qui est impossible à faire en dehors de l'exécution).
Un fouillant un poil j'ai retrouvé le doc d'origine : http://www.cs.utexas.edu/users/lin/cs380c/dynamo.pdf effectivement c'est bien sur du matériel HP que la dynamo a été implémentée en premier.
[^] # Re: ...
Posté par Jerome Herman . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 4.
Oui et non, C'est la première version ou chaque machine Erlang peut s'appuyer nativement sur plusieurs CPU sans efforts de la part du programmeur. Il a toujorus été extrèmement facile de faire tourner un programme Erlang sur plusieurs CPU voir sur plusieurs machines distinctes en mettant les différents process communicants sur différentes machines. Au final il était tout à fait possible de tirer parti de l'architecture complète (mais il est vrai que celà demandait une certainne finesse programmatique).
[^] # Re: ...
Posté par Jerome Herman . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 4.
Il tend à s'allonger si on ne fait rien oui. Mais par contre plus on a de couches disponibles plus on va pouvoir faire d'optimisations post-compilation.
En C on ne peut pas faire d'optimisation à posteriori, une fois que le porgramme est lancé, sa partie executable (ie par la partie données) ne bouge pas sauf cas super particuliers et très casse gueule tel que l'assembleur automodifiant ou le self linking dynamique.
A l'inverse les programmes tournant sur une machine virtuelle peuvent s'optimiser tout seul en permanence. Par exemple lorsqu'il passent dans une fonction ils peuvent créer une table de hashage des paramêtres passés et de leur résultats et ainsi répondre instantanément si la fonction est appelé deux fois avec les mêmes paramêtres. De même ils peuvent faire sauter un paquet de tests et donc linéariser le code. Pareillement la machine virtuelle peut conserver une empreinte de la config système et ainsi court-circuiter un paquet d'appels systèmes en n'executant pas le bytecode et en plaçant la réponse directement au bon endroit etc.
En d'autres termes on passe d'un mode de calcul de branchement, éventuellement de prédiction de branchement à un mode de branchement direct.
A l'heure actuelle ces optimisations post-execution ne sont pas encore très rentables par rapport à la complexité qu'elles induisent dans la machine virtuelle, mais elles le deviennent. Sur des protocoles de communications complexes il est certain que les machines virtuelles finiront par battre à plate couture les programmes compilés traditionnels gràce a des meccanisme de prise d'empreinte mémoire et système qui leur permettront d'éviter la grosse majorité des tests.
[^] # Re: ...
Posté par Jerome Herman . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 4.
Tu attends dix ans. Les vieilles machines auront fait de gros progrès d'ici là.
Si t'utilises gcc, ben il est C ANSI strict et il marche sur tous les Unix, et plein de processeurs non ?
Non. a) Il n'est pas C ANSI strict, il peut se comporter comme C ANSI strict si on lui demande. Sinon il fait aussi du C ISO et si on ignore les warnings dans un cas comme dans l'autre on peut glisser assez loin de la norme.
b) Ce qui marche (plus ou moins bien) sur un paquet d'Unix c'est le trio GCC+Autotools et make+GLibc/Libc . Il existe entre les différents composants un degré de compatibilité assez élevé qui fait que les applications sont raisonnablement portables d'un systeme à l'autre, cependant on est loin de pouvoir prendre un programme Linux x86 pour le compiler sur uen station HP-UX.
La machine virtuelle est une émulation, donc c'est moins rapide
CF mon exemple de la Dynamo, parfois c'est plus rapide car plus flexible et donc optimisable pendant l'éxecution du code.
[^] # Re: ...
Posté par Jerome Herman . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 7.
Ca n'est (et heureusement) plus le cas. Linux est passé en mode NPTL depuis un petit moment, donc on a des vrais threads sous Linux et non juste des processus à moitié forkés.
Personellement ca fait pratiquement deux ans que ma Glibc est en NPTL only (elle ne supporte plus du tout les linux threads) et ca marche très bien (sauf pour MySQL, mais c'est un autre débat).
Maintenant les threads sont des entités dépendantes du processus (ie tous les threads d'un process sont ratachés à l'ID de ce process et le kernel ne voit qu'un seul process) et en plus on a une API standard pour créer toutes sortes de threads, les mutex et les sémaphores qui vont avec.
[^] # Re: ...
Posté par Jerome Herman . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 6.
Houlà, de moisn en moins vrai çà. Les processeurs commencent à être suffisament costaud poru que l'on puisse s'éloigner assez fortement du langage machine sans que celà pose de problèmes de perfs. Encore plus fort : sur une machine raisonnablement chargé (ie 50% de load CPU moyen) une machine virtuelle peu battre un programme natif. Par exemple toujours sur les codes clients/serveurs une fois la connexio établie il y a pleins de tests, de branchements et de boucles qui deviennent innutiles. Lors d'une éxecution dans une machine virtuelle on peut faire sauter tous ces ralentissements inutiles (Technique d'optimisation post bytecode par linéarisation) et le gain de performance est loin d'être négligeable. A titre d'éxemple le programme Dynamo qui est une machine virtuelle proche des processeurs alpha (i.e : un alpha virtuel) permet un gain jusqu'à 15% de performance sur des programmes nativement compilés pour alpha quand on l'execute sur un alpha.
Pour faire plus court, certains programmes alpha tournent 15% plus lentement quand ils sont executés directement sur un processeur alpha que quand ils sont executés sur une Dynamo sur un processeur alpha.
Portabilité : C gagne grâce aux différents compilateurs.
Pas tout à fait vrai non plus, tout d'abord parceque même si il y a pas mal de compilatuers, très peu sont C Ansi strict. Ensuite en C l'OS influence souvent beaucoup la programmation (Il suffit de comparer du code win32 avec du code GlibC pour comprendre). De toute les façons si le framework est bien fichu, il est quasiment impossible de battre en portabilité une machine virtuelle qui possède la triple compatibilité API/ABI/Source .
Lisibilité : Erlang gagne car il a des fonctions déjà toutes prêtes.
On peut cependant écrire des choses relativement illisibles en Erlang et utiliser des bibliothèques qui rendent le code très lisible en C. Après c'ets plus une question de méthode et de propreté du codeur.
[^] # Re: ...
Posté par Jerome Herman . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 10.
Ca dépend ? Qui veux-t-on comme gagnant ? Si on veut juste se rassurer sur l'inutilité à apprendre un autre langage que le C je suggère le calcul de décimales de Pi ou des suites de Fibonacci en mono processus - mono utilisateur. Le C devrait plier à peu près tout ce qui passe. Erlang va apparaitre comme lent et gourmand en mémoire.
Par contre si on s'amuse à faire un bête programe qui créé 200 serveurs intersynchronisés (comme par exemple pour un MMORPG) et que l'on connecte dessus quelques dizaines de milliers de clients on risque d'avoir 99% des programmeurs C qui vont avoir vraiment du mal. Alors que les programmeurs Erlang ayant un peu d'expérience devraient s'en sortir tous a peu près convenablement. Alors après reste la question de savoir qui entre le meilleur programmeur C et le meilleur programmeur Erlang du monde remporterait la palme. En toute honnêteté ce serait probablement le meilleur programmeur C du monde, mais le meilleur programmeur Erlang du monde aurait à coup sur un code maintenable par d'autres que le meilleur programmeur Erlang du monde.
Erlang à un très fort overhead (charge initiale), donc lui faire éxecuter des petits programmes en boucle le met forcément en position de faiblesse. Ceci dit il scale (monte en charge) très bien (très très même).
De toutes les façons, le langage Erlang est certes turing complet, mais il est destiné très prioritairement aux applications communicantes (archi point à point, client/serveur, n tiers etc.) de fait le comparer avec un langage aussi généraliste que le C n'a pas grand intéret. On pourrait éventuellement imaginer un bench d'une bibliothèque réseau ou IPC face à Erlang, mais comparer brut de décoffrage C et Erlang revent à la bonne vieille comparaison entre le couteau et la fourchette.
# Il savent plus quoi faire pour avoir de la pub chez Sun
Posté par Jerome Herman . En réponse au journal Ubuntu sur station sun ?. Évalué à 2.
Aujourd'hui ils font des Machine a base de PowerPC livrée avec une Ubuntu pré-installé pour le calcul massivement parallelisé
Et demain Johnatan Schwartz fait un disque avec le foetus du deuxième bébé de Britney Spear et place la musique en Creative Commons
A Noter que ca fait des années que Sun fait le coup de "libérer" son archi/son OS/sa techno etc. Et que pour l'instant tout ce qu'on a c'est un morceau de Solaris pour x86 et trois lignes sur les controleurs de disques SCSI des Sun - Fire....
# Une autre chanson des CSS
Posté par Jerome Herman . En réponse au journal La chanson du css.... Évalué à 6.
CSS R.S !
CSS R.S !
C'est quand tu manifestes ta joie d'utiliser les feuilles de style.
# I am quite sorry to have to say this :
Posté par Jerome Herman . En réponse au message create user imap with with php. Évalué à 2.
Basically the question you are asking makes little to no sense at all.
There are many questions you should ask yourself, the first one being "were are my users, and how are they managed ?". Are they virtual users managed by your mail server (Postfix, sendmail or wathever), real users created on a specific computer or on a specific domain (basically can you log on a computer using the mail credentials ? ) or is it a groupware thing, with a big LDAP/Kerberos Behemoth behind and an IMAP connector in front ?
Creating the user is quite dependant of this.
The you say you do not want to create the mail box, is it because the IMAP connection is just meant as an access to shared folders ? (and so the user won't recieve mail), is it because you plan on creating the mailboxes later, or you plan on having everyone accessing a same common mailbox (like all member of a staff accessing the staff mailbox), or is it because the mailboxes already exists and you just want to make the IMAP server aware of them.
There are also questions about the authentication method (SASL, Kerberos, IPSec etc. ) wether you already choose a PHP framework to work with or want to code everything yourself (the later will take months) and some niceties on wether or no you plan LDAP or X500 integration (which can be with or without SSO).
Basically, you need to sit down and think about what you are trying to achieve precisely, then you will be able to search the net for answers.
[^] # Re: Faut pas réver
Posté par Jerome Herman . En réponse au journal HD - DVD, Blue-ray... et Linux ?. Évalué à 7.
Et le bruit, ben ca empeche de profiter de la qualite sonore.
Donc mp3 ou flac dans un train, sur un grand boulevard ou autre, je pense pas que ca fasse une grosse difference.
Détrompe-toi. Plus il y a de bruit environnant, plus la musique est difficile à écouter. Donc dans la rue il est plus fatiguant d'écouter de la musique que dans une pièce cloisonnée. L'oreille a moins de travail à fournir pour reconstituer les "bouts" manquants. Seulement si on est dans la rue ET que la musique est de mauvaise qualité, l'oreille a double boulot
a) séparer le bruit environant du signal percu
b) reconstituer les fréquences et sons manquants du signal perdu à cause de la qualité.
Bref écouter de la musique de mauvaise qualité dans la rue est quelquechose de très pénible. On est obligé pour faciliter la perception de pousser le volume à bloc sinon c'est innécoutable. La différence sur 10 minutes d'écoute en millieu bruyant entre du MP3 192 et du OGG 9,5 (ma qualité de référence) est flagrante même pour un non mélomane. Ecouter un morceau en MP3 que l'on ne connait pas déjà par coeur relève de la gageure.
Bref il est d'autant plus important d'avoir une bonne qualité quand on est dans un millieu bruyant que quand on est dan sun millieu calme. Si vous ne me croyez pas vous n'avez qu'à écouter une heure de FM chez vous dans votre chambre puis écouter une deuxième heure de FM dans la rue.
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par Jerome Herman . En réponse à la dépêche Sortie d'OpenBSD 3.9. Évalué à 4.
Façon de parler bien sur. Il a rien dit de méchant. Il faut voir que Theo était auteur de pilotes professionnel avant même de rejoindre NetBSD. Donc parler avec les différentes salles techniques des fabriquants il connait un peu.
En ce qui concerne les drivers crackés et la SAV, franchement s'ils conçoivent du matos mal foutu qui grille à la première fausse instruction c'est un peu de leur faute (je met un CD ultra-techno dans ma chaine, si elle grille c'est la faute au fabricant)
Oui mais les fabriquants pour éviter de dépenser trop de frics dans 50 000 chaine sde montage ils ont une seule chaine et dérrière ils testent. ca tient 200Mhz => top rpoduit. Ca tient 180Mhz => moyen produit. Ca tient 150Mhz => bof rpoduit. Ensuite la différence c'est un ou deux petits bits dans le firmware. Des fois aussi ils se content d'éteindre des fonctionnalités dans la puce grace un quelques bits dans le firmware et un gros morceau dans le driver, des trucs auquel l'utilisateur a pas droit parceque c'ets pas uen carte top produit bien sur, mais aussi des trucs expérimentaux qu'on a quand même laissé dans le tape out mais dont on saity qu'ils marchent pas bien. Alors hop désactivés logiciellement.
Dérrière le driver alternatif il te propose bien sur de mettre la vitesse maximale et d'activer pleins de fonctions expérimentales. Et dans certains cas (souvent chez les mecs qui commencent à bidouiller pour voir) frouf la carte.
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par Jerome Herman . En réponse à la dépêche Sortie d'OpenBSD 3.9. Évalué à 3.
Au final ils ne veulent pour rien au monde perdre la main sur leur projet et ils ne font pas dans le compromis. Hors ca c'est pas très interressant pour les fabriquants.
L'intransigence de Theo est ce qui donne sa force à OpenBSD, masi c'ets aussi ce qui le coupe des sponsors. Autant on est prêt à investir dans un projet en création à conditin d'avoir son mot à dire, autant il est plsu difficile d'investir dans un projet qu'on ne peut absolument pas influencer. Au final pour des groupes comme HP ou IBM donner de l'argent à OpenBSD reviendrait soit à payer un produit (OpenSSH) qui est un produit déjà fini, déjà maintenu et déjà disponible, soit à faire du mécénat sur les futurs produits d'OpenBSD. Mais ca n'est pas vraiment un investissement.
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par Jerome Herman . En réponse à la dépêche Sortie d'OpenBSD 3.9. Évalué à 3.
C'est presque celà, mais pas du tout.
Il ne faut pas oublier que les fabricants ont presque toujours fait du propriétaire
Pas du tout en fait, les matériels (jusqu'en 94-95) étaient fournis avec l'ensemble des specs et souvent le schéma matériel et le schéma logique de la machine. Les 286 IBM, les premières sparc et les premières station DEC étaient même fournie avec la structure des pros en bonus. La mode du propiétaire a été instaurée tout d'abord par adaptec qui a commencé à blinder ses piotes et ses specs SCSI dans tous les sens aux alentours de 95. Derrières les autres boites ont suivi (malheureusement). On a eu droit tout d'abord à uen explosions de dongles et de cables bizaroïdes dans tous les sens et pusi on s'est lentement acheminé vers le proprio tel qu'on le connait maintenant.
leur faire comprendre qu'il n'y a réellement aucun risque à publier leurs spécifications ou alors que le risque est acceptable étant donné la possibilité d'avoir de nouveaux clients
Si seulement, on ne compte malheureusement pas les personnes qui veulent absolument mettre le dernier drivers cracké comme un goret par un hacker de l'autre bout du globe et qui permet de gagner 2% de perfs sur certaines applications. Bon des fois le dit drivers fait partir le matos en fumée, lequel matos se retrouve alors en SAV et va savoir si c'est vraiment un défaut ou si le mec a fait n'importe quoi avec. Bien sur sur le matos "haut de gamme" pour els serverus de grande entreprises le risque est plus réduit que l'ingénieur système en place s'amuse à toucher les paramètres pour voir "ce que ca fait". Mais bon sur le haut de gamme il y a souvent des accords croisés, des partenariats et des NDA dans tous les sens. Donc pas de specs publiques non plus.
Cependant, je n'ai pas l'impression que des efforts diplomatiques ont été fait pour la libération des spécifications des différents matériels, ou du moins ça n'a pas été médiatisé sur les médias du libre.
je me permet de placer ici deux citatiosn de Theo de Raddt :
Trad : Les donnations de matériels ne viennent pas des fournisseurs qui utilisent OpenSSH sur des morceaux de leurs produits. Elles viennent de particuliers. Les fournisseurs de matériel qui utilisent OpenSSH sur tous leurs produits nous ont donné un total de un ordinateur portable depuis que nous avons développés OpenSSH il y a 5 ans. Et il a fallu demander pendant un an. C'était IBM
Trad : Alors le mec de HP vient vers moi (a la conférence de Melbourne) et il dit, " si vous dites des choses aussi méchantes que çà aux fournisseurs, vous n'êtes pas prêt d'obtenir quoi que ce soit". J'ai dit "Non, en huit ans sans rien dire, on a rien obtenu, et je vais commencer à dire des choses méchantes dans l'espoir que certains de ces fournisseurs commeceront à me donner de l'argent pour que je la boucle."
En bref la méthode diplomatique a été essayée. Elle a échoué.
[^] # Re: Linux
Posté par Jerome Herman . En réponse à la dépêche Sortie d'OpenBSD 3.9. Évalué à 8.
Le vrai problème d'ATI (le coté macrovision étant annecdotique) est un problème de fonctionnalités sur lesquelles ils n'ont pas l'ensemble des droits. A la vitesse à laquelle vont les technos 3D aujourd'hui, même un gros poisson comme ATI ne peut pas se permettre d'avori uen équipe R&D assez importante pour trouver des méthodes pour implémenter toutes les fonctionnalités demandées à une carte graphique de nos jours. Pour combler les lacunes ils font appel à des sociétés extérieures (ils ne peuvent pas tout racheter non plus). Ces sociétés extérieures, ne vendent pas du produit mais du papier, elles n'ont donc non seulement aucun interet à ce que les specs de elur focntions soient révélées, mais elles ont même clairement interet à ce que ca reste le plus secret possible (parceque défendre en tribunal que tel implémentation d'un "shader register combiner" est en fait une copie de leur implémentation à eux c'est pas gagné).
Si on ajoute à celà qu'avec les specs complète d'une carte il tout à fait possible de s'arranger pour qu'un jeu brille sur une carte et soit très lent sur une autre (on ira même jsuqu'à dire que ca a déjà été fait plusieurs fois), on comprend vu la fascination qu'ont les power-gamer pour les benchs alac que les fabriquants de puces n'aient pas vraiment envie de fournir toutes leurs specs.
[^] # Re: Les blobs c'est l'amoco cadiz !
Posté par Jerome Herman . En réponse à la dépêche Sortie d'OpenBSD 3.9. Évalué à 10.
Ce qui ets encore plus fort, c'est que si j'ai envie de me servir du channel 13 pour faire de l'émission hors batiment (ce qui en France est interdit) Il suffit de dire au binaire que l'on habite au canada ou à singapour.
Donc on appréciera le haut niveau de protection et de forcage des normes offert par les blobs en question.
# Il a rien compris au libre
Posté par Jerome Herman . En réponse au journal Stallman et les autographes payant. Évalué à 10.
Quel idiot, si il était passé par un modèle libr epour ces autographes, il aurait eu toute une communeauté pour les signer à sa place. En plus il y aurait probablement eu des versions améliorées de sa signature beaucoup plus rapide à faire.
Ce que c'est que d'être prisonnier d'un modèle payant propriétaire....
[^] # Re: Ldaps
Posté par Jerome Herman . En réponse à la dépêche Sortie d'ejabberd 1.1.0. Évalué à 2.
Avec tout le respect que j'ai pour le travail effectué par ton équipe et toi, je pense que tu vas un poil trop loin là. Le jour ou tu envisagera de faire de l'IPC en passant par ejabberd ca sera un signe.
On sera obligé de te soigner à coupde stage de programmation d'access par visual basic, et c'est pas beau à voir.
# Excellent.
Posté par Jerome Herman . En réponse au journal tic tic tic. Évalué à 8.
# Dans l'ordre
Posté par Jerome Herman . En réponse au journal Le retour d'Henry. Évalué à 10.
S'abstenir de tout commentaire sur les filles qui ne portent pas de soutien gorge.
Dans un deuxième temps il convient de s'occuper du fax. Soit la remise en place d'un nouveau rouleau prend quelque seconde et Henry et rompu à cette manipulation et on a un nouveau rouleau à disposition, soit il convient de donner rapidement un petit coup de clef dans le piezzo-buzzer du fax pour le faire taire (généralement il est possible avec un entrainnement minimal de rammener le bruit à un léger sifflement audible amis non agressif ). Si le piezzo buzzer est innaccessibles au clefs de Heny un simpel arrachage de prise peut faire l'affaire.
Troisième étape,
On a actuellement dix à douze minutes de retard il convient à ce moment là
a) de savoir si oui ou non il y a un autre fax dans la boite, si c'est le cas téléphoner à Raymond en lui communiquant le nouveau numéro.
A noter qu'il aurat fallu procéder de cette façon avant de se lancer dans le remplacement du rouleau.
Si il n'y a pas d'autres fax dans les bureaux changer encore uen fois le rouleau de fax
Si il n'y a pas d'autres rouleaux de fax d'avance essayer la combinaison mail + imprimante. Si Raymond n'a pas de mail ou d eversion electronique du papier, appeler "allo course" et lui faire prendre les papiers chez Raymond directement (j'espère que Raymond à au moins une photocopieuse).
Si Jean-mi a eu le temps de réhabiller sa fille et recommence à raler lui demander pourquoi alors qu'un fax papier normal avec mémoire coute moins de 200¤ on se trimbale toujopurs une horreur à rouleau. (C'est bas mais ca soulage).
Poster un grouillot à attendre que les feuilles arrive (devant un des fax ou devant le batiment dans le cas de la solution "allo course") Partir en rendez-vous avec environ 15 minutes de retard.
Si c'est un rendez-vous avec les chefs (plusieurs) tout va bien, les chefs ont souvent au moins 16 minutes de retard, vous avez donc une minute complète pour aller jusqu'à la salle de réunion.
Si le RDV est avec un fournisseur. Lui rappeler gentillement que le client est roi (non pas gentillement en fait.)
Si le RDV est avec un client, apporter les cafés, s'excuser platement. Le chef de la bande (Jean Mi ?) Peut même évoquer le mal qu'il y à bosser avec des passionnés-perfectionnistes (mais pas trop, le client aime que l'on respecte lmes délais).
Débaler le dossier, et faire mine de se rendre compte qu'il manque les douze dernières pages. Henry demande à Jean Mi de lancer la réunion et il part chercher les feuilles manquantes.
a) Si sa colique le reprend il peut ainsi refaire un pause. En profiter pour méditer sur la nécessité qu'a un homme qui fait facilement des coliques d'avoir en permanence sur lui de l'immodium et du charbon actif.
b) Si les pages sont arrivées (il a bien du s'écouler 5 ou 10 minutes) il le sprend et il retourne en réunion
c) si les pages ne sont pas arrivés il donne els indications au grouillot pour les lui apporter le plus vite possible une fois qu'il les aura et repart en réunion.
Il faut ensuite tenir assez longtemps sur les X premières pages du rapport pour que les 12 dernières pages arrivent.
Ca devrait passer normalement. Pas glop, masi il est trop tard pour avoir l'air super pro. Si le projet est bien ficelé et el dossier bien construit pas de problème. Si c'était du pipotron ca casse.
# Ca va il nous reste encore un peu de marge.
Posté par Jerome Herman . En réponse au journal Parce que c'est ça, un geek ?. Évalué à 10.
Si on prend l'échelle naturelle de l'évolution poste darwinienne nous avons :
LUSER (en français : utilise à tuer)
PEBKAC (problem exist between keyboard and chair - interface clavier-chaise déficiente)
NOOB
NERD (seule étape facultative de l'évolution - on peut passer de noob à geek directement)
GEEK
WIZARD
GURU
MOTKU (Master of the known universe - place vaquante depuis que Seymour CRAY est décédé - contrairement à ce que prétendent les masses désinformantes pomophiles, Steve Jobs ne sera jamais MOTKU)
On a encore un peu de marge avant de s'être tout fait bouffer.
[^] # Re: L'avis d'un étranger
Posté par Jerome Herman . En réponse au journal [HS] [CPE] L'avis d'un étranger. Évalué à 0.
J'avais bien compris, mais je pense qu'il était bon de rapeller qu'il y avait une partie non négligeable du chiffre d'affaire produit par els salariés français qui ne rentrait pas dans les statistiques.
Je sais que ces chiffres ne sont pas exactement comparables. cependant comme il était demandé le taux d'imposition "global" dans la prise en charge de la "flexsécurité" il fallait à mon sens rapeller que la sécurité de l'employé avait aussi un cout très lourd.
[^] # Re: L'avis d'un étranger
Posté par Jerome Herman . En réponse au journal [HS] [CPE] L'avis d'un étranger. Évalué à 1.
Pour rappel en France l'employé moyen est imposé/taxé à hauteur de 70% de son chiffre d'affaire en moyenne. (Personellement je tourne à près de 75%)
A ce niveau là on est imbattable, et on a pas la "flexsécurité" (sic).
Donc je pense que le niveau d'imposition global du Danemark, ca serait plus une bulle d'oxygène qu'une aggravation.