lasher a écrit 2758 commentaires

Il va falloir encore que je me répète. Soupir.

LLVM est une toolchain géniale. Mais la license ultra-permissive made-in-apple de LLVM a juste ouvert la porte a une génération entière de compilo dégeulasse qui resteront imbuvables et buggés alors que ces même compilateurs étaient sur la voie de l'exctinction, pour le bien commun.

LLVM est issue de la recherche US. La « licence ultra-permissive » de LLVM (récemment changée en licence Apache 2.0, soit dit en passant, à cause d'abus sur les brevets logiciels), elle vient de la communauté scientifique qui a fait naître le projet. Le projet vit très bien, malgré ses financeurs tant privés (Apple, Nvidia, etc.), que publics.

Soit dit en passant, Nvidia, via la compagnie PGI, propose un compilateur C/C++/Fortran avec OpenMP et OpenACC… basé sur LLVM. Donc s'ils cherchent encore à se débarrasser de GCC pour Cuda, je suis étonné qu'ils ne l'aient pas fait depuis, car ils ont clairement les compétences pour découpler tout ça (surtout que Clang/LLVM prend officiellement compte de propriétés GPU depuis quelques temps).

Le vieux dogme BSD "vous verrez, ils reviendront au libre quand ils verront que c'est mieux pour eux" ne marchent pas et n'a jamais marché et ne marchera jamais.

Les gens qui utilisent une licence BSD ne pensent pas de cette manière à ma connaissance. C'est plutôt : « On fait du soft de pointe, on est bon, si tu veux rendre le soft proprio, pas de souci, mais comme on le fait évoluer vite, si tu nous livres pas tes modifs, ce sera à ta charge de porter toutes tes modifications spécifiques sur les nouvelles versions, y compris quand on aura décidé de casser des bouts d'API. »

Lorsque je regarde les 4 plus gros contributeurs de Clang entre 2007 et 2019, on a 2 dév de chez Apple, Chris Lattner (papa de LLVM, ex-Apple, maintenant chez Google), et un Richard Smith, un dév faisant partie du comité de normalisation de C++ (et "owner" de Clang++). En zoomant sur 2018-2019, Richard Smith passe nº1, un autre dév Apple est nº2, etc. Si je mate les dévs de LLVM depuis ~2018, le numéro un vient de chez Sony, les deux suivants on ne sait pas, le 4è vient de chez AMD, et le 5è vient de chez Google. Donc on a bien un minimum de mutualisation du développement par des gens payés pour le faire.

Donc, que des éditeurs de logiciels sortent des compilos « horribles » propriétaires basés sur LLVM : grand bien leur fasse. Le projet LLVM lui-même continue d'avancer, et de proposer plein de trucs chouettes.

l y a toujours eu la question sur par exemple est ce ok qu'un
mafieux soit en prison sous excuse bidon plutôt que la réalité?

Genre le fait que Al Capone soit tombé pour fraude fiscal ?

La fraude fiscale n'était pas bidon. Capone fraudait bien le fisc US. Et là-dessus, ils ont pu le prouver, et les peines maximales étaient bien celles déjà en place – c'est juste que d'habitude elles ne sont jamais mises en œuvre.

Culture du viol? Aux USA, es-tu sûr?

Je ne sais pas si tu es ironique ici, mais oui, aux US, les agressions sexuelles (au sens légal US) et les viols, même « minoritaires » (les chiffres varient grandement en fonction de ce qu'on qualifie en tant que viol ou agression), restent un vrai fléau.

Ensuite, l'expression « culture du viol » pointe sur quelque chose de très précis.

le viol n'est pas toléré ni encouragé par la société,

Je te propose de regarder un peu mieux les séries policières US qui sont un genre absolument roi aux US (et mÊme en France jusqu'à un certain point), et où les scènes de policiers interrogeant des suspects et leur rappelant qu'ils vont sans doute se faire violer en prison (sous-entendu : et ils l'auront bien cherché) abondent.

Je pense qu'il est compréhensible qu'on ait poussé Stallman vers la sortie après son mail pour des raisons évoquées par d'autres plus haut, mais ce que dit Vice et que tu rapportes :

Stallman wrote that the “most plausible scenario” is that Epstein’s underage victims in his campaign of trafficking were “entirely willing."

… est faux. J'ai lu le mail en question. Ce n'est pas ce qu'a dit Stallman. Il dit que très certainement ces filles « donnaient l'impression d'être consentantes » (sous-entendu : car sous la coupe d'Eptstein). Ce n'est pas la même chose que dire qu'il affirmait qu'elles étaient effectivement consentantes.

Grâce aux adverbes entre autres. Si je dis, « Je regarde ça demain » ou « Je regarderai ça demain », les deux sont compréhensibles de la même manière.

Bref, il faut contextualiser.

Justement, c'est un sujet qui n'a aujourd'hui pas de réponse évident : qu'est-ce qui est le plus efficace entre inciter ou contraindre?

Je pense qu'aux débuts du LL, oui, contraindre était important, car tout un tas d'éditeurs (Microsoft en tête, mais clairement pas qu'eux) voulaient clairement piéger les utilisateurs dans leur environnement. En particulier, il fallait qu'une masse critique d'utilisateurs et producteurs de LL soit atteinte pour que les logiciels ne se retrouvent pas absorbés par des éditeurs tiers¹. En ce sens, le GCC initial (et donc pas EGCS qui a suivi fin des années 90) ne me choque pas dans son couplage fort front-end/back-end, car oui, un certain nombre de compagnies étaient prêtes à cannibaliser ce genre de softs difficiles à écrire sans reverser quoi que ce soit à la communauté (et oui j'insinue que pas mal étaient prêtes à violer la licence, car pas de communauté du libre très organisée ni très nombreuse pour contre-attaquer comme c'est possible maintenant).

Concernant la GPL v3, c'est aussi un peu la faute aux gros éditeurs logiciels qui abusent des brevets logiciels : l'exemple de Microsoft qui a fait payer un gros nombre de fabricants de smartphones ou d'environnements grand public basés sur Linux/Android est assez criant en ce sens. Pour Linux/Android c'était trop tard, car forcément sous GPLv2, mais pour les futurs logiciels mis sous GPL je peux parfaitement comprendre.

Ce qui d'ailleurs me fait réagir à un de tes commentaires précédant dans ce fil (je crois) : si Linus Torvalds ne met pas Linux sous GPLv3, c'est parce que d'une part je crois bien qu'il a dit qu'il ne voyait pas l'intérêt (mais ça à la limite, on pourrait aussi imaginer que les gros contributeurs puissent le réclamer s'ils le voulaient vraiment), mais aussi (et surtout ?) parce que de toute manière ce n'est pas possible, étant donné qu'il faudrait l'aval de tous les contributeurs du code existant dans le noyau, alors que certains sont décédés.

Rien de nouveau de la part d'Apple, GCC les embêtait déjà avec ça (et d'autres choses) ils ont juste décidé de faire un truc mieux (LLVM) techniquement sans passer son temps à bloquer les évolutions techniques pour forcer les gens à faire ce qu'ils ne veulent pas faire

LLVM est un compilateur issu de la recherche publique US, absolument pas financé par Apple à la base. La communauté LLVM orientée logiciels libres était déjà établie au sein de l'enseignement supérieur et de la recherche US quand Apple a commencé à s'y intéresser. De nos jours il est vrai que le plus gros financeur de LLVM est Apple, mais l'impulsion initiale est bien celle de la NSF aux US (et pas mal de contributions continuent devenir de labos/universités du monde entier). Sinon, oui, la licence type BSD est clairement ce qui a attiré Apple, au moment où les nouvelles versions de GCC passaient en GPL v3.

Mais je pense que rappeler que Apple s'est largement appuyé sur les efforts communautaires est important : DarwinOS est une combinaison de noyau Mach et d'environnement FreeBSD, et les compilateurs itou (GCC/LLVM+Clang). Et évidemment, ils ont bien raison de profiter de cela, mais j'aime bien rappeler que tout un tas de trucs qui sont désormais largement financés par des boites aimant plus ou moins enfermer leurs utilisateurs dans un écosystème donné (ça vaut aussi pour Google et Android par ex) le font grâce à des efforts communautaires importants.

… D'expliquer un peu plus, non ? Quelle grande administration ?

Je viens beaucoup moins souvent qu'avant, donc pas sûr que je sois vraiment indiqué pour répondre à ça mais… en tant que Vieux Con (TM), je ne lis jamais la section liens, du coup ce qui y est posté ne change en rien mes habitudes : journaux d'abord, puis page des nouvelles (avec possiblement quand même les nouvelles tout en haut de la page d'accueil en premier).

Et de temps en temps les forums (mais vraiment pas souvent).

J'ai récemment fait l'acquisition de canards en plastique aux couleurs de différents lieux que j'ai visités. J'ai hâte de leur expliquer mes problèmes de bug.

Le staff de LinuxFR se débrouille très bien depuis plus de 20 ans, et quelque part, je dirais même qu'ils passent à l'échelle. :-)

AMD veut coller au standard et développe en open-source

Ça me semble quand même être une technique classique du challenger/outsider de faire du dev libre/open source lorsqu'il ne domine pas le marché visé dans le cas de constructeurs de matériel un peu sophistiqué. Par exemple, Intel a des drivers libres pour ses GPU parce qu'il s'est complètement planté avec ses tentatives de cartes graphiques 3D/GPU (voir aussi : Larrabee, devenu Xeon Phi, abandonné au bout de 2 générations). Ils proposent même un runtime OpenCL libre (au moins sous Linux; je crois qu'une implémentation Windows était en cours il y a quelques temps).

Je pense que Zenitram a raison : on a deux composants logiciels, A et B, tous deux inclus dans de grosses distribs. Bien. Il y a des cas documentés/avérés de plantages lorsque A utilise B. Bien bien. Du coup les dévs du composant A décident que le composant B est trop problématique (possiblement à tort, mais c'est suffisamment un souci pour qu'ils se soient posé la question pendant de longs mois avant de réagir).

Si la/les distributions qui intègrent les deux composants estiment que c'est une exagération des dévs de A, les mainteneurs du paquet A n'auront qu'à patcher le code pour effectivement donner le choix à l'utilisateur. Je trouve que c'est finalement assez logique, et cohérent avec la façon dont les distributions Linux ont fonctionné jusqu'à présent.

C'est vrai, MAIS : le problème est qu'on ne parle pas que d'une tâche qu'on automatise, mais d'un ensemble de tâches au fil de l'eau. Il faudra ainsi additionner le nombre de tâches qu'on répète plusieurs fois dans la journée/le mois/l'année et leur durée pour réellement identifier ce que la somme agrégée nous coûte en temps.

Il faut aussi considérer l'aspect énervement/agacement/fatigue (mentale ou physique) à devoir répéter les mêmes tâches, parfois fastidieuse (même si possiblement rapide) plusieurs fois dans la journée, même s'il s'agit de « micro-tâches », car elles coûtent aussi en « context switch ».

(bon sinon j'aime bien ce xkcd :-))

Larry Wall (papa de Perl) le dit très bien (et je le cite régulièrement) : un bon programmeur a trois qualités :

1. La paresse : s'il faut faire plus d'une fois un traitement similaire, autant l'automatiser.
2. L'impatience : le soft ne va pas assez vite, ou ne devine pas suffisamment à l'avance ce que je veux faire. Il va falloir améliorer ça.
3. L'orgueil : lorsqu'on lui signale un bug, le bon programmeur prendra ce bug comme une offense, et ira le corriger aussi vite et bien que possible.

Idem aux US. Après, dans ces pays, beaucoup de boulots qualifiés sont aussi mieux payés que leur équivalent en France (en particulier en info). En contrepartie, le salaire minimum est bien plus bas qu'en France (et je ne parle même pas de l'équivalent de la sécu aux US).

Tout à fait d'accord sur le fait que la programmation parallèle est un sous-ensemble (important !) de la programmation concurrente. Après, comme d'autres l'ont fait remarquer, il existe plusieurs sortes de parallélisme. En calcul scientifique, on utilise souvent le parallélisme de données – c'est l'exemple qu'avait donné quelqu'un ici à propos des chats qui mangeraient dans la même gamelle. Un autre type de parallélisme est celui des tâches : c'est ce qu'on fait, par exemple, lorsqu'on repasse une chemise tout en écoutant la télé/radio, et possiblement en parlant avec quelqu'un. Enfin, il y a le parallélisme de pipeline, qui « chaîne » différentes tâches pour qu'elles traitent un bout de donnée successivement. Évidemment, on va fournir un autre bout de donnée à la première tâche dès qu'elle aura passé son bout de donnée traité à la suivante, etc. On peut imaginer une chaîne de montage façon « Les temps modernes », par exemple. Évidemment, on peut mélanger les trois (sinon ce ne serait pas drôle !).

Lors d'une conférence il y a longtemps, le keynote speaker avait proposé une illustration de la différence entre programmation parallèle et programmation concurrente en pratique :

En voyant une nouvelle machine de type supercalculateur, data center, etc., le programmeur parallèle s'extasie et s'écrire : « Ouahou, quelle puissance potentielle ! On va pouvoir faire des choses formidables avec ça ! »

En voyant la même machine, le programmeur concurrent prend une expression horrifiée, et se lamente : « Regardez toutes les possibilités de panne dans cette machine ! »

Un bon exemple de la différence de point de vue est dans l'utilisation d'une bibliothèque de communication et calcul très utilisée en calcul intensif/haute-performance : MPI. Les utilisateurs de MPI le font généralement sur une machine avec réseau d'interconnexion dédié (pas de TCP, trop lourd; pas d'Ethernet, trop lent – au moins niveau latences). Ils se posent des questions compliquées liées à la topologie sur le réseau, combien de sauts il faudra peut-être faire en regardant les machines utilisées, etc.¹ Au contraire, les programmeurs de la bibliothèque MPI locale doivent tenir compte de toutes les possibilités de panne temporaire ou permanente (les appels MPI de base sont bloquants, et attendent des acquittements de bonne réception/terminaison d'envoi de données; même la version asynchrone de ces appels fait de même, peu ou prou). Ils doivent composer avec les possibilités de congestion sur le réseau, et pour les versions les plus sophistiquées, prennent en compte tout un tas de possibilités de pannes transitoires ou temporaires.²

Le programmeur parallèle d'une grappe de calcul essaie de trouver des algorithmes et des implémentations qui iront vite pour une application donnée, en considérant que tout ira bien, c'est-à-dire, en faisant abstraction quasi-complètement de la couche réseau (et en-dessous). Le programmeur concurrent va devoir considérer que les latences d'envoi/réception peuvent varier, et même imaginer quel genre de panne peut survenir, et s'il veut y remédier.

Je suis à l'étranger et je ne pourrai pas aller POSS cette année. Je souhaite un bon anniversaire à LinuxFR malgré tout, et j'espère que vous aurez l'occasion de voir plein de contributeurs. :-)

Spolsky a des défauts, mais les langages qu'il utilise sont ceux de son industrie (il fait des trucs Web, donc il faut penser PHP, JavaScript, ASP, .Net, etc.).

J'aime bien le typage statique, mais ça n'empêche pas qu'il existe des cas compliqués ou à la marge. Par exemple : programmation parallèle en mémoire partagée. C'est pour ça que j'aime préfixer mes variables quand elles sortent du contexte « normal » qu'on s'attend à trouver. Par exemple :

#include <pthread.h>
#include <stdio.h>
#include <stdint.h>

#define N 100ul

volatile int g_COUNTER;

typedef struct { 
    int id;
} id_t;

void* worker(void* arg) {
    id_t id = (id_t*) arg;
/*  Façon très mauvaise de créer une section critique dans le cas général */
    while (g_COUNTER != id->id)
        ; //nothing
    ++g_COUNTER;

    return 0;
}

int main(void)
{
    pthread_t threads[N];
    id_t      ids[N];
    for (size_t i = 0; i < N; ++i) {
        ids[i].id = N-i-1;
        if (0 != pthread_create(threads+i, NULL, worker, ids+i))
            abort(); // pour faire simple
    }

    for (size_t i = 0; i < N; ++i)
        if (0 != pthread_wait(threads[i], NULL))
            abort(); // pour faire simple

    printf("counter = %d\n", g_COUNTER);
}

Dans ce contexte, presque tout suit une convention de nommage classique, mais mes macros sont écrites en majuscules pour bien montrer qu'on parle de constantes (N), et pour mes variables globales, je préfixe par g_ ET je mets en majuscules, parce que dans un contexte multi-threadé, on ne met jamais trop d'avertissements dans le nom de la variable pour qu'on se souvienne qu'il faut faire attention ⇒ g_COUNTER.

Investir raisonnablement n'implique pas qu'on va réussir.

Ai-je dit le contraire ? :-) Ce que je décris est effectivement la présence de gardes-fou pour éviter les financements participatifs qui se résument plus ou moins à une arnaque. Tous les sites ne le font pas (et évidemment, même chose pour un employé ou une boite bien entendu). Par contre, je trouve que ton post laissait entendre que c'était la loi de la jungle pour le crowdfunding. Pour les grosses plates-formes, il s'avère que pas trop, non. Et ce n'est pas juste une histoire d'image de marque dans le cas de KS : pour tout ce qui est US, c'est aussi une protection légale au cas où des gens victimes d'arnaquent se retournent contre le prestataire.

Exception : les (enseignants-)chercheurs ! \o/

Et en l'occurrence il n'y a peut-être pas d'obligation de résultat, mais au moins avec Kickstarter il faut quand même pouvoir démontrer que les sommes collectées ont été investies raisonnablement. Je ne sais plus pour quel projet ça avait été fait, mais en gros la personne qui avait récolté un beau pactole l'avait investi dans complètement autre chose que ce qu'il avait promis, et KS l'a poursuivi en justice, comme il était promis en cas de fraude avérée (et remontée par les utilisateurs).

Nessus aussi était copyleft, et le problème était double :

1. Les « experts » sécu lançaient Nessus sur des machines (serveurs et clients) windows, Nessus ne disait rien, et ces super consultants disaient que le réseau était clean. Sauf que… La distribution de Nessus (en GPL2) ne contenait que les filtres pour Unix/Linux, et pas de filtres spécifiques à Windows (c'était comme ça que les gens de Nessus espéraient se faire des sous, entre autres).
2. Tout un tas « d'experts » se contentaient de foutre une interface graphique par-dessus Nessus, changer les noms ici ou là dans le programme, et surtout, surtout, venaient avec « leurs » outils, en modifiant le soft ou en le corrigeant, sans rien reverser au projet, et sans dire au client d'où venaient leurs outils (c-à-d : en mentant). Et ça, y'a zéro moyen de se prémunir contre, car l'outil ne sort pas du laptop ou de la clef USB du « consultant ». Il n'y avait donc aucune reconnaissance ni contribution au projet (malgré l'aspect illégal de certaines pratiques, mais qui sont impossibles à vérifier/établir en pratique). C'est ce qui a poussé les auteurs de Nessus à fermer (dans le sens : rendre propriétaire) leur projet.

Je ne suis pas dev C++ (enfin, si, mais non). Je suis à fond pour C++11 et ses copains¹. Mais dans tous les cas je suis d'accord que (1) Tous ces nouveaux mots-clef et mécanismes sont utiles, mais que (2) ils n'en restent pas moins abscons pour quelqu'un d'un peu extérieur².

Je rajouterais que, tout comme pour C (qui est toujours enseigné comme si C99 et C11 n'avaient jamais existé³), C++ reste la plupart du temps enseigné par des gens qui ne se mettent pas à jour en termes de normes. Et je ne parle même pas des gens qui enseignent le C++ en « premier langage » alors qu'en fait on parle plutôt de « C avec std::cout » (même si la POO tend à suivre ensuite).

Du coup je veux bien que quelqu'un me parse la ligne initiale. :-) Mon C++ est très balbutiant car j'ai peu d'expérience avec mis à part certains mécanismes directement utiles pour mon boulot.

Je comprends ce que tu dis. Cependant, encore une fois, tout est histoire de contexte.

Histoire de dresser un peu le tableau : les formations en informatique comptent entre 15 et 20% de femmes (en étant assez optimiste : en génie électrique et informatique industrielle, on est plus proche de 10%; en informatique de gestion, on tourne effectivement autour de 15-20%). On retrouve cette proportion dans les métiers de l'informatique (admin, dév, etc.) en général (peut-être un peu plus, autour de 20-30% si on considère les personnes qui aident à la rédaction et traduction de doc technique, specs, etc.).

Il faudrait que je retrouve des informations et sources fiables (et surtout, à jour), mais la dernière fois que j'avais participé à une discussion sur le sujet (sur LinuxFR je pense), on comptait entre 5 et 10% de femmes qui participaient régulièrement et activement à des projets open source (et ça diminuait encore plus si on se concentrait sur le côté développement uniquement). Un recherche rapide me donne cet article, qui cite entre autres cette publication sur la population de StackOverflow.

On observe donc que les femmes sont largement sous-représentées dans les projets libres, à hauteur de ¼ à ⅓ par rapport aux autres projets informatiques.

Ceci étant posé, lorsque tu dis

En gros : je préfère "si vous voulez encourager les gens à contribuer à linux, …" plutôt que "si vous voulez encourager les femmes à contribuer à linux, …"

… la seule chose que j'ai envie de répondre est oui, mais non.

Premièrement, je vais me permettre de faire une analogie pas si foireuse que ça (je pense). Prenons la mesure (et l'optimisation) de performance dans une application. Lorsqu'on évalue la performance d'une application, on utilise perf, gprof, oprofile, etc., et on détermine là où on perd le plus de temps dans le programme. Dans mon expérience, il y a généralement deux gros types de profils qui émergent :

1. On passe un temps relativement égal (à 5% près) dans toutes les fonctions du programme. Dans ce cas, on doit faire un boulot super chiant d'examiner les fonctions une à une et voir s'il n'y a rien d'évident à optimiser tout de go dans chaque fonction, mais de façon générale, on peut arguer qu'à moins de changer certains algorithmes ou structures de données fondamentaux pour le fonctionnement du système avec d'autres qui assurent la même fonction mais pour une complexité moindre, on ira grapiller les % de perf là où on peut.
2. Le programme passe un temps non-négligeable dans 1, 2, ou peut-être 3 fonctions, et le reste du temps est morcelé en fractions de pourcents pour toutes les autres. Par exemple : lorsque 50% du temps d'un programme est passé dans une fonction unique, il semble évident qu'on va devoir régler ce problème en priorité. Une fois que cette portion de code a été optimisée et son temps d'exécution est divisé par deux, deux choses arrivent : la fonction en question ne prend plus que 25% du temps original d'exécution total, mais aussi : en réalité, elle prend malgré tout 30% du nouveau temps d'exécution. Une fois que cette optimisation a été effectuée, on re-mesure le tout, car de nouveaux effets peuvent avoir été déclenchés et changer un peu la donne en termes de performance.

Si je reprends le cas de la représentation des femmes dans les projets libres :

1. Le HOWTO qui nous intéresse indique clairement qu'il concerne ce qu'il faut faire (selon ses auteurs) si un LUG veut attirer plus de femmes. Les quelques points que l'on a discuté (ne pas critiquer trop lourdement, encourager, etc.) sont à remettre dans le contexte d'une section qui parle principalement (sans exagérer) de ne pas avoir un comportement sexiste, de ne pas harceler une femme qui viendrait voir de quoi il retourne, et de ne pas réifier les femmes (je te laisse aller vérifier sur le lien que j'avais posté).
2. Si je reprends mon analogie de la mesure et optimisation de perfs, il me semble (personnellement) évident que le fait qu'il y ait des hommes qui n'oseraient pas contribuer au dév du noyau (et qui auraient les capacités pour le faire) est bien moins préoccupant que le fait qu'il y ait 70% de femmes en moins en proportion dans les projets libres que dans les autres projets info ¹. Il faut d'abord régler ce problème, on verra ensuite comment les choses évoluent.

Mon intuition est qu'une fois que le problème de comportement envers les femmes est résolu (et encore une fois, même s'il y a sans doute des instances de sexisme sur la LKML et dans le dév/la communauté libre en général, je ne pense pas que, par exemple, Torvalds soit lui-même sexiste), alors le cas des hommes dont tu parles le sera aussi par effet de bord.