lasher a écrit 2732 commentaires

Il faut faire attention avec ce genre de raisonnement. La question à laquelle il faut répondre est : « la population dans son ensemble (y compris les producteurs de contenus culturels), ou en tout cas une proportion non négligeable de celle-ci sort-elle gagnante de l'instauration d'une taxe pour copie privée ? ». Que dans ton cas personnel, tu ne regardes pas les séries ou des films, que tu n'écoutes jamais de musique, etc., n'est qu'une goutte d'eau. Ton argument ressemble fort au « Je ne suis jamais malade, pourquoi devrais-je cotiser à la sécu ? » — et selon moi, ça le rend invalide.

Par contre les différents arguments que je trouve valides (et qui ont été exposés dans divers messages de cette dépêche) sont les suivants :

1. Dans 99,99% des cas, les entreprises et professionnels qui achètent des supports de stockage le font pour stocker autre chose que de la musique ou des films.
2. La taxe est imposée sur tout support de stockage, sans prendre en compte dans quelle proportion ces derniers sont réellement utilisés pour stocker du contenu issu de la copie privée.
3. À chaque fois qu'un individu achète un support de stockage, il est taxé dessus, même si les copies privées qu'il a effectuées sont stockées sur un support différent, de façon unique. Ainsi, on présuppose qu'à chaque fois que j'achète un support de stockage, c'est principalement dans le but d'user de mon droit à la copie privée.
4. Il y a des utilisateurs qui trouvent que centraliser leurs CD et DVD sur un support de stockage unique est bien plus pratique (j'en fais partie). Et donc, d'un point de vue pragmatique, il y a bien une copie privée effectuée, mais cette dernière devient la « copie utilisée » de fait. Qui plus est, c'est toujours la même paire d'oreilles qui écoute/regarde ces enregistrements, et donc à tout moment une seule de ces copies est active, et écoutée par le propriétaire du support original de l'œuvre.
5. Il y a une double peine pour les gens qui achètent de la musique en ligne et qui … la stockent sur un support de type disque dur ou baladeur MP3.

Je ne suis absolument pas hermétique à une notion de taxe permettant à l'exception de la copie privée d'exister. Par contre, mon problème est que le législateur n'a pas révisé la portée de la loi concernant la versatilité des supports de stockage, ni les changements concernant les marchés audiovisuels. Considérer que dans 95% des cas une cassette audio sert à copier de la musique déjà produite par un tiers, ce n'est pas idiot (les 5% restant concernent les groupes qui enregistrent avec un matos vaguement pourri leurs maquettes, ainsi que les programmeurs de TI99A, de MO5, et autres ordinosaures). Faire la même supposition dans le cas des CD, clefs USB et autres disques durs, par contre, c'est méconnaître (on va leur laisser le bénéfice du doute) l'usage réel qu'en font les utilisateurs dans leur ensemble.

Tu peux rentrer chez moi proprement a 4 heures du mat' quand je dort et faire le tour de la maison sans rien toucher, et repartir en fermant la porte, ca ne me cause aucune perte et ne me derange techniquement pas, est ce que c'est ok?

Tu fais comme si les situations étaient comparables. Encore une fois, tu as tout d'abord dû entrer dans un lieu matériel. Mais admettons, tu ne touches à rien, tu ne changes rien, etc. Tu m'as vu dans une situation intime, qui n'appartient qu'à moi, et qui n'était pas destinée à être diffusée ou affichée. C'est la grosse différence ici je trouve. On ne parle pas de gens qui copient la musique ou le film jamais diffusés sur les ondes; on parle de choses destinées à la diffusion contre rémunération. Les contextes sont fortement différents et je trouve ta comparaison peu pertinente.

Maintenant soyons clairs : je suis pour l'existence d'un droit d'auteur, et je suis pour la rémunération des personnes qui ont permis la diffusion des diverses œuvres (musicales, télévisuelles, etc.). Mais je suis contre l'abus évident des droits qui se rattachent au droit d'auteur, surtout quand dans de nombreux cas il ne s'agit pas nécessairement de la volonté de l'auteur à proprement parler, mais de l'éditeur/de la maison de disque/de la chaîne de télé — ou pire, des ayants droits après la mort de l'auteur.

Le point de Tanguy peut sembler extrême, et son exemple des immeubles vides encore plus, mais il y a une certaine cohérence : il n'y a aucun problème à faire du bénéfice grâce à une œuvre, ou bien grâce à la location d'un bien, etc. Par contre, il peut sembler moralement répréhensible d'abuser de cette notion de propriété, dans le sens où diffuser une œuvre dans une région particulière et pas dans une autre est souvent complètement arbitraire et n'a rien à voir avec la volonté de l'auteur de l'œuvre dans de très nombreux cas¹. Dans le cas des immeubles, si le propriétaire garde l'immeuble vide et fait des rénovations, ou bien a un projet affiché de faire quelque chose de cet immeuble, je pense que la plupart des gens diraient juste « mince, dommage ». Mais les immeubles dont parle Tanguy sont maintenus vides exprès, pour pouvoir vivre de la spéculation pendant que des gens dorment dehors, faute de revenus suffisants (une grande partie des SDF a un boulot, au moins à temps partiel). Et oui, il s'agit de spoliation (et je ne dis pas que je suis forcément d'accord²), mais d'un point de vue moral, je comprends parfaitement, et ça a une certaine logique.

Encore une fois, je pense que le problème et le débat ne concerne pas le droit qu'a une personne sur un bien (physique ou immatériel), mais sur l'abus que cette personne fait de ses droits.

Ben on va tourner en boucle. :)

C'est différent de la même façon que voler une voiture soustrait un objet non-reproductible à son propriétaire, là où la copie ne fait « que » le multiplier. :)

Pardon, j'étais resté sur la discussion initiale : contourner les limites arbitraires de diffusion ou télécharger des productions qui sont indisponibles dans certaines régions du monde.

Si dans ta famille, vous possédez une maison familiale d'été utilisée rarement, cela ne te dérange pas que des gens viennent confisquer le bien de ta famille ?

Pas comparable : tu parles d'un bien matériel, dont seule une petite population peut jouir à la fois. L'exemple que tu donnes ensuite est du même acabit.

D'où ma remarque sur « le ras-le-bol doit être suffisamment général », ce qui implique que les proches des soldats sont aussi touchés. Mais j'ai bien conscience que ça n'arrive pas tous les jours. En même temps, les révolutions n'arrivent pas tous les jours non plus, ça tombe bien.

Désolé, j'avais vu le post mais oublié de répondre. Donc :

Je disais :

[…] L'État a le 1er budget militaire au monde, et la 2è armée au monde. Entre les soldats et les drones, en quoi former des milices va-t-il aider ?

Tu répondais :

Le peuple peut renverser les USA, malgré sa force militaire […] La guerilla ça a marché partout : Espagne, Cuba, Afghanistan, Irak, Vietnam, etc.

Tu as raison, mais dans le pire des cas, l'état US pourrait balancer des missiles/des bombes sur les endroits les plus emmerdants niveau révolte/révolution, et je ne sais honnêtement pas si les ambitions de révolte d'un peuple y résisteraient.

Ou alors tu considères que l'armée faisant parti de la population, en tant que 1ère armée du monde le peuple n'aura pas besoin de se battre, c'est parié sur le ralliement des militaires à la population plutôt qu'au gouvernement.

J'en parlais ailleurs : la Révolution française a pu entre autres se faire grâce au concours d'une bonne partie des militaires. Ça ne signifie pas que ça arrivera à tous les coups, et tu as raison de souligner que beaucoup de dictatures s'appuient sur l'armée, mais tout dépend aussi du contexte. Si la liberté de parole reste relativement ouverte malgré l'oligarchie/la dictature sous-jacente (comme au XVIIIè siècle en France), et si suffisamment de gens en ont ras-le-bol, alors le militaire « prolo » aura sans doute de l'empathie pour ses potes/sa famille/ses voisins non militaires mais qui souffrent du régime. Tous les militaires n'aideront pas dans l'optique d'une révolte/révolution, mais si les conditions économiques et politiques sont suffisamment mauvaises, j'y crois. Dernier exemple en date (qui a mal tourné) : l'Ukraine. Le président ukrainien a accepté un pot de vin de ~15G€ de la part de Poutine, et en retour a empêché le processus d'adhésion de l'Ukraine à l'UE. Résultat : révolte.

Je disais aussi :

si on doit pouvoir former une milice contre la tyrannie potentielle de l'état, doit-on autoriser toute forme de vente d'armes à ses citoyens, y compris nucléaires ?

Tu répondais :

Le but est plutôt d'autoriser l'acquisition d'une arme pour se défendre, ça ne précise rien de plus. Le nucléaire étant sous contrôle de l'État fédéral, il en garde le monopole d'utilisation (et je crois que les traités internationaux interdisent une telle revente). Mais l'État ne peut empêcher la vente d'une arme quelconque à un citoyen si la chaîne a été acquise légalement.

Sauf que tout un tas d'armes sont interdites à la vente car considérées comme armes de guerre. j'ai cité la bombe A car c'est le plus évident, et c'est un exemple « tarte à la crème ». En règle générale, il y a tout un tas d'armes « lourdes » interdites à la vente aux US, et qui peuvent tirer plusieurs dizaines (centaines ?) de balles à la minute.

Du coup, même si ton argument concernant la guérilla est juste, je pense qu'avec le type d'armée qui existe aux USA, espérer pouvoir se soulever et gagner sans le concours des militaires eux-mêmes est futile.

La notion de milice était clairement pensée à une époque où il n'y avait pas d'armée américaine, et où les Britanniques étaient l'ennemi (qui, lui, avait une armée, et pas des moindres). Elle était aussi pensée dans le cas où aucune autre forme d'ordre n'était disponible localement. Aux US il y a réellement deux types d'interprétations de la constitution US : ceux que j'appellerais les « littéralistes » et les « spiritualistes » (dans le sens qu'ils pensent à l'esprit de la constitution). Malheureusement, dans la bonne vieille tradition anglo-saxonne, le « littéralisme » est clairement gagnant, et ce, depuis au moins 15 ans (certains diraient depuis l'époque Reagan). C'en est à un point que pas mal de conservateurs et libertariens récrivent plus ou moins l'histoire : certains affirment que les fondateurs de la constitution US étaient chrétiens et voulaient un état chrétien, alors qu'en fait la moitié était agnostique au mieux, et tous étaient sécularistes/laïques. C'est une façon pour ces gens d'expliquer que la notion de « liberté de religion » dans la constitution indique qu'il y a nécessairement une religion, et que donc l'athéisme n'est pas concerné par cette dernière (c'est de la foutaise bien entendu). D'autres expliquent que Lincoln n'aurait rien du faire concernant l'émancipation des esclaves, car l'esclavagisme était en train de mourir partout ailleurs en Europe, et que donc ça allait arriver de toute manière, et que ça a coûté une guerre civile et des morts inutiles (ils ne répondent généralement rien quand on leur demande leur avis sur les vies et les morts des esclaves qui seraient restés sous le joug de leurs maîtres). Tous les historiens s'accordent à dire que c'est de la foutaise, mais leur voix n'est pas aussi porteuse que ces cadors.

Désolé, j'ai débordé un peu. :(

Ben écoute, tu peux faire des remarques brutales, et littleboy peut te répondre brutalement. Ça me semble équitable. :)

Lorsque tu rejoins un projet, tu t'adaptes aux besoins du projet. Dans le cas d'OpenBSD, ils ont décidé de rester sur CVS. C'est un choix discutable. N'empêche, c'est le choix de gens qui ont décidé de se retrousser les manches pour proprifier un code réputé dégueulasse. Donc tu as le choix : utiliser LibreSSL, un CVS « daté », mais actif, avec des gens qui cherchent à faire les choses bien; ou utiliser le git utilisé par le projet OpenSSL, mais qui se traîne des bugs et des archaïsmes désormais connus de tous.

Si j'avais à faire de la maintenance de code, ou à ajouter un algo de crypto à l'un des deux (en supposant que je n'ai besoin que de POSIX, et pas de Windows ou VMS), mon choix serait vite fait.

Il faut se souvenir de la Révolution française ! :-)

Le peuple a pu se soulever entre autres grâce au concours des soldats de l'armée du roi (au moins une partie). Pas besoin de posséder une arme, il suffit que le ras-le-bol soit suffisamment général, les inégalités suffisamment insupportables pour qu'un soldat qui a un pote, une mère, ou quelqu'un de proche en général et qui souffre de cela (en plus de tous les autres) pour que par empathie il vienne aider un mouvement populaire de masse.

Cet argument est contesté même aux USA, sous plusieurs aspects :

• L'esprit de la constitution US (la milice en question était là à cause de l'empire britannique)
• La lettre de la constitution (ils vont jusqu'à argumenter sur la présence ou l'absence de virgule, si si)
• Le côté pragmatique : si on doit pouvoir former une milice contre la tyrannie potentielle de l'état, doit-on autoriser toute forme de vente d'armes à ses citoyens, y compris nucléaires ?
• Le côté pragmatique (bis) : une milice privée ? Contre le grand-méchant état ? Comme c'est intéressant. L'État a le 1er budget militaire au monde, et la 2è armée au monde. Entre les soldats et les drones, en quoi former des milices va-t-il aider ?

La mode en ce moment, c'est d'expliquer que ce ne sont pas les flingues qui tuent, mais les malades mentaux qui ont mis la main sur ces flingues.

Tiens tu as raison, le show est dispo sur amazon… C'est un import Zone 1 sur amazon… Ah merde mon lecteur DVD ne m'autorise pas à le lire…

Rien ne t'empêche d'acheter un lecteur multi-zones — c'est légal en Europe, et ça ne coûte plus grand chose. Ou d'utiliser VLC qui ne vérifie pas les zones.

Dans le cas d'émissions télés qui sont diffusées sur le net, le seul autre moyen légal serait que la chaîne qui finance le show soit accessible (via CanalSat, ou autre fournisseur de chaînes câblées ou via la pose d'une antenne satellite avec possibilité de capter les chaînes US). Aucune de ces solutions n'existe pour Comedy Central à ma connaissance. Il n'y a AUCUN recours légal pour vivre là où tu vis, et malgré tout avoir accès à ce contenu.

Tanguy se place d'un point de vue moral, et tu dis que moral ou pas moral, il faut voir si ça empêche les gens qui possèdent les droits d'auteur ou le copyright AUTRES que les producteurs et présentateurs directs (donc la chaîne Comedy Central, etc.) de faire du profit (je ne vois aucun autre moyen d'être lésé).

D'un point de vue pécuniaire, il n'y a aucune perte d'argent, et du point de vue moral, parce qu'ils estiment qu'ils ne peuvent pas faire de fric (ou bien parce qu'ils ne veulent pas dépenser les sous à embaucher un traducteur pour mettre des sous-titres) ils décident que personne d'autre que le peuple nord-américain aura le droit de mater leur émission. Pour le dire autrement : ils interdisent l'accès à plusieurs émissions parce qu'ils trouvent qu'il n'y a pas de perspective de profit à laisser l'accès libre à quelque chose qu'ils proposent de toute manière en accès libre pour peu que tu aies une IP qui a un préfixe qui leur plaît. Ça ressemble un peu à un sketch d'Élie et Dieudonné : « J'ai une émission télé, et quand on a une émission télé, on a pas le droit de la prêter. »

Pour reprendre ce que tu disais :

Ah mais c'est cool ca, je peux diffuser un fork proprio de linux alors.

Ils vont pas perdre d'argent vu qu'ils ont pas specialement envie de diffuser en non proprio!

Non, tu renverses la raison pour laquelle le droit d'auteur en France a été créé : parce que des gens comme Beaumarchais écrivaient des pièces, n'avaient pas forcément de problème avec les gens qui copiaient et jouaient la pièce sans lui payer un sous, mais par contre il avait clairement un gros souci avec les imprimeurs et éditeurs qui copiaient le texte en lui-même, et revendaient la chose sans rien lui reverser. Pour simplifier : tant que c'est pour un usage non-commercial, il se fichait qu'on copie ses œuvres. C'est quand des gens ont commencé à se faire du fric sur son dos qu'il s'est fâché.

L'exemple du Daily Show est celui de spectateurs qui assistent à une « représentation ». L'exemple que tu donne est celui d'un éditeur ou imprimeur qui reprend le contenu produit par quelqu'un, et cherche à se faire du fric sur son dos. La nature de la copie est complètement différente : dans un cas il y a « soustraction » (se faire du fric sans rien reverser), dans il y a multiplication (au pire par 1, donc aucun avantage; au moins par n, c'est-à-dire qu'ils s'ouvrent des horizons pour potentiellement voir qu'il y a un marché réceptif à ce genre d'émission).

Je vais citer le cas bien connu de « Shaolin Soccer » qui, sans l'immense partage dont il a bénéficié sur le net à l'époque n'aurait pas pu déboucher sur la diffusion dans les salles de ciné du film en question, ainsi que la diffusion d'autres films de Stephen Chow.

Idem pour le film « Bride ce Nice », qui n'aurait jamais pu voir le jour sans le partage monstrueux de 3 sketches sur le net. Le film est une bouse, mais il n'aurait jamais pu voir le jour sans le partage d'une certaine « propriété intellectuelle » (quelle expression de merde).

Tout ceci étant dit, il est possible qu'une chaîne de télé française ait acquis les droits de diffusion du Daily Show et du Colbert Report, et que du coup il y ait une demande d'exclusivité. C'est ce qui était arrivé entre 2007 et 2009 avec Canal+ (qui — surprise ! — avait fini par créer le petit journal).

Le fait qu'ils ne perdent pas d'argent vu qu'ils ne veulent pas spécialement diffuser l'émission dans les pays non-anglophones?

Que ce soit « The Daily show with Jon Stewart », « The Colbert Report », ou maintenant « Last Week News with John Oliver » (ces deux derniers étant des transfuges du Daily Show), il s'agit d'émissions satiriques qui utilisent l'actualité pour se moquer d'un peu tout et n'importe quoi. L'émission de Colbert est à mourir de rire selon moi, et a un gros avantage : elle permet (selon moi) de comprendre une bonne partie de la façon dont les américains pensent la moralité, la religion, et la politique.

J'ai tendance à comparer le Daily Show à une sorte de Canard Enchaîné télévisuel. Lorsque j'avais expliqué le contexte à des amis français, j'avais eu droit à un « ah ouais, comme le petit journal quoi », ce qui m'avait surpris. Quand je suis parti de France, le petit journal n'avait pas exactement la même formule. Lorsque j'ai effectivement regardé une émission plus récente, il m'a paru clair qu'ils avaient repris pas mal de choses du Daily Show. Avec cependant de grosses différences à mon avis : d'une part, le Daily Show essaie toujours de remettre les extraits qu'ils diffusent dans leur contexte, même si juste derrière ils vont critiquer/se foutre de la gueule des protagonistes; d'autre part, il leur est déjà arrivé (souvent, d'ailleurs) de se planter¹, et du coup d'avoir des moments « pan sur le bec ».

Dans tous les cas, je trouve que ces émissions sont extrêmement importantes, puisqu'elles permettent de mieux comprendre la culture US (la France a vraiment pas mal de préjugés sur les US qui mériteraient d'être révisés et contredits). Elles sont aussi hilarantes (à mon avis), justement parce qu'elles utilisent l'actualité comme moyen de faire de l'humour.

Du point de vue de la langue, Colbert² est sans doute plus facile à comprendre que Stewart (ce dernier a tendance à parler un peu vite, comme pas mal de gens issus de New-York ou du New Jersey). John Oliver a commencé son show sur HBO il y a 3 semaines, et c'est en gros un Daily Show sans la censure de la télé US traditionnelle (i.e., il peut montrer des seins ou un pénis à la télé, il peut dire « fuck » sans qu'il soit bippé, etc.). Comme Oliver est un Anglais qui a vécu aux US pendant ~15-20 ans, je trouve que son anglais n'est pas trop « british », et assez facile à comprendre.

Dernière chose : Colbert a accepté de remplacer David Letterman (un géant des talk shows américains), et donc son personnage d'ultra-conservateur va disparaître à la fin de l'année. Profitez-en pendant que vous le pouvez !

Merci de la réponse. Et oui, je me suis mélangé les pinceaux entre hachage et adressage ouverts. Je suis un peu surpris pour la notion d'adressage qui serait plus susceptible à une « mauvaise » fonction de hachage. Le clustering dont tu parles va aussi arriver avec un hachage ouvert (sous forme de liste chaînée), et du coup au moins dans le cas de l'adressage ouvert, il me semblait qu'on bénéficiait au minimum d'une allocation mémoire contiguë garantie.

Je réfléchis « à voix haute » :

• dans le cas du hachage ouvert (table + listes chaînées), on peut garantir une insertion en à tous les coups
  • il suffit d'insérer l'élément en début/fin de liste, indépendamment de toute forme d'ordre;
    • par contre, si on veut éviter les doublons, alors il faut parcourir la liste chaînée (complexité ) pour vérifier que l'objet n'existe pas déjà.
  • conséquence : en cas d'accès en lecture, il faudra compter sur une complexité en pour récupérer l'objet.
• Dans le cas d'un adressage ouvert, si un objet différent existe déjà à l'adresse (ou indice) de la case déterminée, on va itérer sur les cases suivantes jusqu'à en trouver une libre.
  • On a donc bien une complexité en cas de collision;
  • pour les mêmes raisons que précédemment, on a potentiellement aussi une complexité pour la recherche d'un objet en cas de collision.

Donc il me semble que dans les deux cas, la complexité en cas de collision est la même. Certes, l'effet de clustering dont tu parles peut aussi arriver (mais après tout, si j'ai une liste chaînée de mes objets en collision, n'est-ce pas quelque part aussi une forme de clustering ?). Mais quand la capacité de ma table à adressage ouvert approche le taux de remplissage fatidique, je dois alors doubler la taille, et re-hacher tous les éléments (qui était l'argument que j'avançais au post précédent). Du coup mes éléments sont potentiellement dispersés à nouveau dans ma table. Et je ne comprends pas bien en quoi c'est pire qu'avec le hachage ouvert (donc avec listes chaînées).

[ Par contre je me dis que si jamais j'ai une table à adressage ouvert, je pourrais potentiellement tenter de trier mes entrées de collision sans doute à l'aide d'un moyen pour savoir combien d'objets ont le même hash, et ainsi ne trier que les entrées importantes¹, avec une complexité de « seulement » . ]

En fait lorsque j'ai lu ton journal (avec intérêt, même si je ne suis pas développeur Java pour deux sous), j'ai été très étonné de voir que la technique de la liste chaînée était utilisée, plutôt que le hachage ouvert pour les tableaux associatifs. Dans tous les cas, entre arbre équilibré (type rouge-noir ou AVL) et table à hachage ouvert, on se retrouve avec une complexité amortie de , alors qu'avec une table + liste chaînée, on dépend « bien plus » d'une bonne fonction de hachage : dans le cas de l'adressage ouvert, il faut doubler la taille de la table et re-hacher les valeurs pour les réinsérer dans la table, ce qui fait qu'une attaque sur les collisions ne devrait avoir qu'un impact limité. Ceci dit je me trompe peut-être (je suis loin d'être un expert en algorithmique).

Tu as raison, le commentaire de la fonction devrait préciser les limitations de celle-ci. Par contre, le coup du « la fonction aura une défaillance une fois sur quatre [dans le cas général] » me semble exagéré.

Imaginons deux entiers, i1 et i2, que l'on soustrait l'un à l'autre. Posons quatre cas de figure:

1. i1 et i2 sont positifs: tout va bien, car dans ce cas « l'amplitude » de la soustraction tient largement dans l'intervalle [INT_MIN,INT_MAX]
2. i1 est négatif, et i2 est négatif : tout va bien pour les raisons exposées précédemment (i2 est complémenté à 2, et tout se passe comme d'hab').
3. i1 est positif, et i2 est négatif. Dans ce cas, il y a un risque d'overflow, car la somme i1 + compl2_i2 (avec compl2_i2 = -i2, positif) peut dépasser INT_MAX.
4. i1 est négatif, et i2 est positif. Pour les même raisons que précédemment, on peut obtenir un underflow.

Donc cette fonction est parfaitement valide pour deux int de même signe que l'on veut comparer. Si les signes peuvent être différents, il faut alors soit changer de fonction, soit avoir des garanties sur la plage de valeurs (pas forcément « petite », mais pour éviter les surprises, il faut garantir que i1 et i2 sont dans la plage [-<TYPE_ENTIER>_MAX/2,<TYPE_ENTIER>_MAX/2].

Certains pourront arguer que prendre un type entier (short,int,long, etc.) et diviser la plage de valeurs par deux n'est pas très malin. Je trouve que c'est discutable, et que ça dépend fortement de la plate-forme visée. Dans le cas d'un code à destination de l'embarqué, chaque octet compte, donc il faut bien faire attention. Dans le cas d'une machine type PC, les données stockées sur le disque prennent bien plus de place que le code (c'est d'ailleurs pour ça que le format Mach-O d'OS X avait été adopté : lorsqu'on a un programme avec 500Mio de données, doubler la taille du binaire pour pouvoir tourner sur PPC et x86 n'est pas un grand prix à payer). En pratique sur une machine 64 bits et conforme à POSIX, sizeof(long) = sizeof(void*) et est la taille d'un registre. Donc du point de vue purement lié à l'efficacité (et pas au stockage en mémoire), que j'utilise un int ou un long ne change rien, tout se passera de la même façon.

Celle où les animateurs de talk shows aux US disent que Heartbleed est un virus ? :-)

Je pense que ceux qui connaissent le monde des *BSD savent de quoi il retourne. Parmi ceux qui connaissent le monde de Linux un certain nombre en sont sans doute encore à penser qu'il faut compiler tous les paquets à la main — alors qu'en fait, non, et que même s'il fallait, le système d'OpenBSD permet de compiler les paquets à recompiler une fois, puis de distribuer le binaire tranquillou pour les autres machines, comme n'importe quelle distribution UNIX ou UNIX-like moderne qui se respecte. Et idem pour FreeBSD et NetBSD.

Par contre, je conçois qu'avoir un binaire compilé par un dev « officiel » d'OpenBSD et dispo quelque part (pas forcément le site d'O/BSD) pourrait quand même en rassurer certains.

Ca dépend d'ou tu bosses chez Google. J'ai des amis qui démentent complètement que les 20% ont disparu.

Pour le même genre d'algo c'est difficile à dire en fait. OpenMP définit les constructions paralleles, mais ne dit absolument rien à propos de l'ordonnancement (mis à part certaines grandes lignes pour l'ordonnancement des boucles parallèles). De l'autre cote, tu as Cilk qui décrit sous quelles conditions le vol de tache est effectué, le genre de structures de données utilisé pour stocker les piles de chaque thread dans le tas (cactus stack), le genre structures de données utilisé pour stocker les taches en attente (deque—double-ended queue), etc.

Bref, certaines implémentations d'OpenMP vont faire du vol de tache, d'autres vont avoir une file d'attente unique et centralisée (beurk), mais surtout, OpenMP n'a aucune garantie à apporter pour ce qui est de l'utilisation des ressources. Si j’écris un truc du genre

void fork_bomb(int n) {
    printf("%d-th iteration\n");
    if (n > 0) {
#       pragma omp task
        {
            fork_bomb(n-1);
        }
#       pragma omp task
        {
            fork_bomb(n-1);
        }
#       pragma omp taskwait
    }
}

/* ou son equivalent Cilk */
cilk void fork_bomb(int n) {
    printf("%d-th iteration\n");
    if (n > 0) {
        spawn fork_bomb(n-1);
        spawn fork_bomb(n-1);
        sync;
    }
}

… dans un cas je peux potentiellement avoir taches créées (même si le taskwait limite quand même pas mal) alors qu'avec Cilk j'ai la garantie d'une exécution bornée en terme d'espace mémoire.

Par contre avec Cilk, tu es cense faire une synchro depuis la fonction appelante pour collecter les threads générés (ce qui garantit la propriété fully strict, qui nécessite qu'une tache fille se synchronise avec son parent direct), alors qu'OpenMP permet de faire a peu près tout, y compris du "strict-tout-court" (qui ne demande "que" d'avoir une tache qui se synchronise avec un ancêtre lorsqu'elle termine): tu peux créer une hiérarchie de taches, et ne demander à faire une synchro qu'avec une tache tout en haut de l'arbre de création.

Concernant Cilk+, j'ai regardé de plus près : ils ont une notation "à la Fortran" pour les tableaux, genre

int tab[MAX][MAX], a[MAX], b[MAX];
for (int i = 0; i < MAX; ++i) 
    tab[i] = 5;

// On peut raccourcir en ecrivant :

tab[0][:] = 5;

// On peut aussi faire des operations sur les tableaux : 
tab[:] = a[:] + b[:];

Ca marche pour les vrais tableaux et les conteneurs types "vecteurs" (i.e., un truc dont les bornes sont connues).

Apres, Cilk+ et TBB ou OpenMP ont des objectifs différents, et sont efficaces pour des classes problèmes différents, de ce que j'ai pige. Ça ne veut pas dire que tu ne peux pas faire une ch'tite multiplication de matrices efficacement en Cilk+, juste que faudra sans doute changer l'algo de partitionnement en blocs.

Oui, il y a des limites avec le Cilk « classique ». Ce qui fait sa force (la notion de fully strict) est en partie sa faiblesse. Cela dit, si j'ai un code fortement récursif (comme le fib de mon exemple), je vais rapidement créer assez de boulot pour le système: chaque fonction appelante est suspendue pour laisser la fonction appelée s'exécuter, mais du coup peut être utilisée par un autre processeur pour continuer le code jusqu'au prochain sync. Donc là où avec OpenMP tu écrirais un truc du genre :

#pragma omp for schedule(static, SEUIL) // SEUIL est le nombre d'itérations à filer par thread
for (int i = 0; i < N; ++i) 
{
    do_something(i);
}

… et en Cilk, on ferait plutôt un truc du genre :

cilk void do_something(int lo, int hi)
{
    if (hi-lo < SEUIL) {
        serial_do_something(lo,hi); // le vrai travail est effectué ici
    } else {
        spawn do_something(lo,   hi/2);
        spawn do_something(hi/2, hi);
        sync;
    }
}

L'approche diviser-pour-regner est inhérente à la programmation pour Cilk. Après, avec Cilk++

Le gros « problème » de Cilk (et ses potes Cilk++ et CilkPlus) selon moi, c'est le fait qu'il nécessite de repenser un partie de ses algorithmes, là où avec OpenMP, on peut prendre du code déjà écrit séquentiellement, et « juste » rajouter un pragma au-dessus d'une boucle (en pratique si tu ne fais pas gaffe, tu vas sans doute avoir des perfs pourries, mais ça ne coûte en tout cas pas grand chose d'essayer pour voir, même si tu n'es pas un expert en optimisation de perfs).

J'oubliais le code du main pour OpenMP :

int main(int argc, char *argv[]) {
   int n,res;
    /* J'omets le code pour lire n sur l'entrée standard */

#   pragma omp parallel
    {
#       pragma omp single 
        {
            res = fib(n);
        }
    }
    printf("fib(%d) = %d\n",n,res);

    return 0;
}

il existe une classe de décideurs pressés qui récupère un max de thune (bien plus que celui qui met ces économies en jeux) et qui prend le risque de se voir remercier avec une prime de départ…

Je suis d'accord, et j'aimerais rajouter que la première règle de l'investissement (je ne parle pas de création d'entreprise), c'est de ne mettre que l'argent dont on est certain de ne pas avoir besoin au moins dans le moyen-terme (et plutôt dans le long terme). Dans une très moindre mesure, lorsque je mets 200$ dans un projet kickstarter, je considère cet argent comme « perdu ». J'espère que le produit que j'aide à financer va se réaliser, mais je n'ai aucune garantie.

Du coup, il est évident que lorsque la famille a déjà une certaine fortune, il est plus aisé pour l'héritier de tenter d'investir (en bourse par exemple), et de se rétablir si ça n'a pas marché.

Un petit mot à propos de CilkPlus. À la base il s'agit d'un environnement de compilation construit sur une version modifiée de GCC (v2.95 je crois, ou peut-être v3.x), produite au MIT. Cilk v5 est un logiciel libre, téléchargeable sur le site du MIT. Il faut se souvenir qu'il a été proposé à une période « héroïque », où il n'y avait pas encore réellement de standard pour exprimer des programmes en parallèle pour machines à mémoire partagée (OpenMP a officiellement proposé son premier standard en 1997). Voici un petit exemple de code Cilk (pas CilkPlus), et son équivalent en C+OpenMP:

/* Version Cilk naïve du calcul des nombres de Fibonacci en parallèle */
cilk int fib (int n) {
    if (n >= 2) {
        int n1, n2;
        n1 = spawn fib(n-1);
        n2 = spawn fib(n-2);
        sync;

        n = n1+n2;
    }

    return n;
}

int main(int argc, char *argv[]) {
    int n,res;
    /* J'omets le code pour lire n sur l'entrée standard */

    res = spawn fib(n);
    sync;
    printf("fib(%d) = %d\n",n,res);

    return 0;
}

/* Version OpenMP naïve du calcul des nombres de Fibonacci en parallèle */
int fib(int n){
    if (n >= 2) {
        int n1, n2;
#       pragma omp task shared(n1)
        {
            n1 = fib(n-1);
        }
#       pragma omp task shared(n2)
        {
            n2 = fib(n-2);
        }
#       pragma omp taskwait 
        n = n1 + n2;
    }

    return n;
}

Ces deux codes font la même chose, mais ce qui est intéressant, ce sont les garanties et innovations offertes par Cilk à l'époque¹:

1. Cilk n'ajoute que trois mots-clé à C89 : cilk, spawn et sync
2. Cilk garantit que l'espace pris par les différentes tâches (pile, etc.) est directement proportionnel à celui du même code tournant en séquentiel, à un facteur multiplicatif près.
3. Cilk était le premier langage parallèle (à ma connaissance) qui reposait sur la notion de vol de tâche, et en faisait une propriété algorithmique. Le vol de tâche consiste à aller « piocher » dans la liste de tâches en attente des voisins une nouvelle tâche à effectuer lorsqu'on n'a rien à faire.
4. Cilk utilise une cactus stack au lieu d'une linear stack (la pile habituellement utilisée par les compilateurs). C'est grâce à elle que le vol de tâche est « aisé » pour le runtime de Cilk².
5. Lorsqu'une fonction parallèle est invoquée, le père est placé dans la liste des tâches en attente, et la fonction fille commence à s'exécuter directement. Cette propriété permet de garantir que l'ordre d'évaluation des fonctions est complètement strict (fully strict dans le texte original). Ça veut aussi dire que si j'exécute un code Cilk sur un seul processeur, il exécutera les fonctions exactement dans l'ordre dans lequel elles seront invoquées, et donc le code s'exécutera comme un code C classique.

Concernant le fait que l'exécution d'un programme Cilk est borné en espace, voici un exemple :

fib(3):
    fib(2):
        fib(1)
        fib(0)
        somme
    fib(1)
    somme
somme

Si j'ai un seul processeur, tout sera exécuté « dans l'ordre ». Si j'ai deux processeurs, alors la séquence devient quelque chose de ce genre (P1 et P2 sont les processeurs de la machine)³:

P2: rien à faire.
P1: depuis fib(3):
    spawn fib(2): fib(3) est placée dans la liste des tâches disponibles. On exécute fib(2)
P2: vol de tâche. P2 récupère fib(3)
P1: depuis fib(2): 
    spawn fib(1): fib(2) est placée dans la liste des tâches disponibles. On exécute fib(1)
P2: depuis fib(3):
    spawn fib(1): fib(3) est placée dans la liste des tâches disponibles. On exécute fib(1)

P1: fib(1) termine. Vol de tâche. P1 récupère fib(2).
        spawn fib(0): fib(2) est placée dans la liste des tâches disponibles. On exécute fib(0)
P2: fib(1) termine. Vol de tâche. P2 récupère fib(2).
    On attend que toutes les tâches générées reviennent.
P1: fib(0) termine. Vol de tâche. P1 récupère fib(3).
    On attend que toutes les tâches générées reviennent.
P2: fib(1) et fib(0) sont revenues. On peut effectuer la somme, et terminer.
P1: fib(2) et fib(1) sont revenues. On peut effectuer la somme, et terminer.
P2: rien à faire.

Ainsi, si les deux codes Cilk et OpenMP se ressemblent fortement, Cilk me garantit qu'il ne créera pas plus de tâches que le nombre de processeurs disponibles. Avec OpenMP et la majorité des environnements de programmation parallèle, si un ordre de création de tâche est effectué, alors celle-ci est crée, qu'on ait les ressources pour l'exécuter ou pas.

Dernière chose : Cilk est le langage qui avait été choisi pour écrire « Socrates », un logiciel d'IA pour jouer aux échecs, et a longtemps été dans le top 3 dans les années 90. C'est aussi le langage qui a au départ été utilisé pour écrire FFTW (The Fastest Fourier Transform in the West), une bibliothèque de calcul de transformées de Fourier parallèle, qui a la propriété rigolote d'être « cache-oblivious » (c'est-à-dire que les algos de FFTW vont naturellement faire « tenir » les données dans les caches). Leiserson est le prof derrière le projet Cilk. Il avait monté une boite pour vendre Cilk++ (une réimplémentation de Cilk en C++, mais qui utilise des mécanismes différents)

Prenons donc funopen
Il est ou? Dans un fichier appelé stdio.h!

C'est vrai. En même temps, contrairement aux headers sous Linux qui me font devenir chèvre à faire des milliards d'#include partout pour trouver la définition d'un type ou la déclaration d'une fonction, les BSD ont une hiérarchie des headers simple qui fait qu'on trouve facilement ce qu'on cherche (enfin en tout cas c'est mon expérience).

De plus je me souviens du temps où la libc sous Linux était le plus souvent la glibc, et du coup elle aussi embarquait un peu 12000 fonctions dans des headers « standards ».

Si tu veux porter, il faut soit modifier le source pour ajouter ton include perso,

Oui, c'est ce que je voulais dire : pour funopen par exemple, il faut clairement pouvoir reproduire la fonctionnalité, ce qui implique écrire une version perso. Idem pour strlcpy ou strlcat. Pour ces dernières, depuis la publication de C11, il existe les fonctions « bornées » (suffixées par _s, genre strcpy_s), qui devraient rendre l'écriture triviale (si le compilateur les implémente).