lasher a écrit 2738 commentaires

La loi de Moore (doublement des transistors sur une même surface tous les 24 mois) est invalidée depuis 5-6 ans je dirais (d'autres iraient p'tet jusqu'à remonter à 2012). On fait toujours augmenter le nombre de transistors, mais il n'y a plus de doublement.

Euh, de ce que me disaient les ingés d'Intel, l'Itanium est surtout mort de leur incapacité à faire baisser la conso de puissance (et du coup le proc était coincé à 1,6GHz).

Le compilo d'Intel était excellent à partir de ~2009 pour l'IA64.

Et quand on y réfléchit un peu c'est bien plus logique d'avoir un prof de latin qui enseigne l'informatique plutôt qu'un prof de maths.

1. Complètement d'accord avec toi sur le fait qu'il ne faut pas que l'informatique soit enseignée comme un moyen de faire des maths, ou une équivalence à faire des maths appliquée.
2. J'y ai bien réfléchi, et ce n'est pas du tout plus logique de faire enseigner la programmation ou l'algorithmique par un prof de latin plutôt que de maths. :-) Ce n'est pas moins logique¹, mais clairement pas plus non plus. À la limite, un prof de philo serait potentiellement plus indiqué, car a priori ce serait quelqu'un habitué à la manipulation de clauses et propositions logiques.

L'utilisation d'exercices pour faire des calculs mathématiques est clairement responsable du dégoût d'une bonne partie des 1ères années en fac dans les années 90 et 2000 en France (DEUG MIAS). Cependant, s'il faut creuser à un moment donné, s'il faut expliquer certains concepts tels que la complexité ou des notions de calculabilité, un prof de maths est a priori plus indiqué.

Et moi en plus en tant qu'apprenant, j'aime bien aller voir ce qu'il y a derrière. Ça sera problématique à ce moment-là également.

Au risque de paraître un peu condescendant plutôt que montant : je ne savais pas que tu étais encore au lycée. :-)

Plus sérieusement, on parle de faciliter la tâche d'un pédagogue pour le lycée. Est-ce que l'outil est bon ? Aucune idée. Il faudrait demander à un utilisateur qui a déjà pris en main ce cadriciel.

Cependant, il faut bien garder en tête qui est la cible : des jeunes de 14-18 ans en moyenne, qui auront un intérêt variable pour la matière. Si cet outil permet de faciliter l'apprentissage de la programmation (et pas seulement l'algorithmique), tant mieux. Le côté « moi je veux voir sous le capot », on ne l'a que rarement en réalité (mais ça arrive bien entendu).

Là où tu y vois un problème, j'y trouve plutôt un intérêt :)

Parce que tu es passionné. On parle d'enseigner les bases de la programmation à une population qui sera très hétéroclite. J'enseigne en IUT GEII (génie électrique & info industrielle/embarquée), et certains sont excellents (ils finissent nos TP de 3h en 1h ou 1h30), et d'autres complètement à la ramasse (un seul exo, ou deux, en 3h, sur les 5 au total). Et là on parle de gens qui ont plus ou moins une appétence pour le sujet (au moins sur le papier).

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.