Renault a écrit 7467 commentaires

Le problème avec ce genre de prévisions, c'est que l'augmentation du chômage c'est l'argument de vente de ces entreprises. Ce dont il est difficile de douter, c'est que la productivité va augmenter. Mais dans l'histoire de l'économie, les gains de productivité ont rarement engendré du chômage, et aucun argument n'est proposé ici pour expliquer pourquoi ce serait le contraire avec l'IA. Ça ressemble donc à de la com pour patrons débiles, genre "grâce à moi il y aura plein de chômage".

Plus bizarre, le patron d'une entreprise qui aurait un tel impact qui fait une telle prédiction cela ne semble pas lui poser de problème. C'est sans doute le plus scandaleux dans l'histoire.

Si tu penses que ta boîte va causer probablement un chômage de masse, tu devrais agir un peu plus que de juste agiter la menace dans la presse. Et en particulier agir pour que cela n'arrive aps en n'étant pas dans la course à qui mettra ces gens là au chômage le plus vite possible.

Donc jusqu'à preuve du contraire, cette histoire de chômage, c'est du bullshit. Les conséquences normales, c'est que les gains de productivité vont engendrer une baisse des coûts, qui vont permettre d'avoir plus pour le même investissement, et donc stimuler l'investissement, et donc la croissance. L'idée c'est qu'une entreprise ou un particulier n'a jamais ses besoins comblés. Une boite ne va pas dire "avant je dépensais 100k€ pour développer mon site web, maintenant je dépense 10k€, youpi, distribuons les 90 k€ gagnés aux salariés (ou aux actionnaires)". C'est juste qu'avec 100k€, tu pourras avoir un truc bien plus riche et/ou fonctionnel et/ou gourmand en serveurs et en bande passante, et tes concurrents aussi, donc tu dépenseras autant pour avoir plus.

Pourtant on l'a bien vu dans l'agriculture et dans l'industrie que finalement les gains de productivité ont eu pour conséquences moins de gens bossent dedans pour produire pourtant plus de biens. Il n'est donc pas absurde que pour le tertiaire l'impact sera finalement le même à la fin. Sauf que tu recases où les gens du tertiaire ? Oui il y a sans doute des métiers qui recruteront encore à balle, mais assez pour absorber le tout ? Pas certain du tout.

Cependant si le chômage est trop élevé, tu as moins de consommateurs potentiels et tu as aussi probablement des contre réactions politiques ou sociétales. Cela risque surtout de diviser la population encore plus entre celle qui gagne bien sa vie et celle qui ne le peut pas faut d'emplois dispos. Ce n'est pas très reluisant.

Et tous les patrons ne sont pas les mêmes, et tous ce qui est produit n'a pas les mêmes contraintes. Oui certains patrons peuvent profiter de l'amélioration de productivité pour produire / vendre plus. Mais d'autres ne le feront pas car pour gagner de la marge c'est plus facile dans ce cas de virer que de produire plus. Surtout que les gens ont des finances et un temps fini, tu ne peux pas surproduire ad vitam eternam.

Bref, si l'amélioration de la productivité a lieu de manière massive, les conséquences sur l'emploi sont réellement possibles.

Non, l'objectif est de pouvoir identifier dans du code C existant des situations d'une manière formelle et d'appliquer une transformation dessus. Cela n'a pas été fait pour créer du code nouveau (à ma connaissance) et les capacités d'expressions semblent vraiment orientées dans une optique de maintenance de code que d'écriture.

En général les patchs générés dans le noyau avec ont la commande associée dans le message de commits pour expliquer comment cela a été obtenu. Je ne trouve pas la syntaxe de Coccinelle particulière lisible ou avantageuse sur ce point, mais c'est efficace pour l'objectif poursuivi car de nombreuses transformations qui semblent simples en apparence peuvent être exprimées de manière différentes et il faut pouvoir les capturer au maximum.

Car des exemples valent mille mots, une diapo qui montre les capacités tirés d'exemples réels : https://events.static.linuxfound.org/sites/events/files/slides/part1.pdf

Problème Rust est particulièrement complexe à cause de ses règles complexes (je pense borrow-checker)… ils ont implémenté les fonctionnalités minimales pour le moment.

Le borrow checker n'est pas le principal problème ici. Le soucis est la richesse de la syntaxe de Rust et la variété de situations qu'il faut couvrir.

Oui Coccinelle naïvement peut servir à automatiser le changement de nom d'une fonction dans Linux. Mais ça à la limite c'est le cas facile en C à gérer.

L'intérêt est plutôt : on a tel objet qui s'initialise d'une autre façon (nouveaux paramètres, nouveau code de sortie, etc.), il faut automatiser la détection et correction du code impacté pour se conformer à la nouvelle manière de faire.

C'est là son point fort surtout pour une base de code si large et avec beaucoup de code qui finalement se ressemble, un pilote I2C reste un pilote I2C, y'en a des centaines qui ont un squelette similaire donc en cas de refonte cela peut vite devenir pénible à faire à la main.

Ce n'est pas pourtant le cas dans les mathématiques appliquées ou ceux qui travaillent en collaboration avec d'autres sciences comme justement la physique ?

L'interdisciplinarité n'a rien de nouveau.

Je connais pas bien le sujet, mais depuis des années (la mort de SJ, quand LT a "officialisé" qu'il avait eu des échanges en vu de recrutement, de la part du PDG d'apple, relayés par la presse spécialisée), certains commentateurs indiquent que la différence de fonctionnement des noyaux de linux et de mach, aurait fait peser la balance.

Ce dont je relate n'était pas d'être un employé Apple (du moins à cette époque là) mais d'associer Apple et l'OpenSource en général contre Microsoft. L'aspect Linux, conception du noyau, etc. c'était totalement secondaire, Jobs n'a probablement jamais été trop impliqué là dedans et s'en foutait pas mal. Mais justement c'était plutôt l'aspect qu'Apple ne comprenait pas l'OpenSource qui lui posait problème pour envisager quoique ce soit avec eux. Il espérait de leur part un peu d'ouverture mais Jobs n'a clairement pas été très réceptif.

Après perso je peux comprendre que quand tu travailles sur ton bébé en étant bien payé pour cela et que tu y prends du plaisir, il faut offrir beaucoup pour accepter un tel changement de carrière. Là encore je ne pense pas que si le noyau d'Apple aurait été "monolithique" il aurait accepté une telle offre de toute façon… Code pas OpenSource, pas son projet, quel intérêt ?

Bien sûr, je ne dis pas forcément le contraire.

Mais j'ai connu beaucoup trop de personnes qui ont été développeurs et qui à force de faire du travail de haut niveau et de management sont bien incapables de suivre une discussion technique.

Oui enfin tout le monde vieilli en 10-15 ans, je ne vois pas le soucis.

Si tu regardes des photos de lui il y a moins de 5 ans c'est à peu près le même. Pour Gates le changement semble plus imoortant. Gates est certes plus vieux mais assez surpris de voir un tel impact en si peu de temps.

En vrai en 20 ans sans toucher du code, c'est facile de perdre beaucoup de notions techniques surtout que durant la période il y a eu de nombreux changements.

Cela nécessite de suivre en détail les avancées pour ne pas être à la ramasse.

Torvalds a surtout refusé parcqu'il travaillait sur un noyau monolithique, alors que mach (de macos) est un micronoyau. Cette différence, semble avoir été principale, par rapport aux autres raisons.

Tu as une preuve de cela ?

Pour avoir lu sa bio pas mal de fois, je n'ai pas le souvenir que cela a été une considération quelconque, pour l'un comme pour l'autre. Ce sont surtout deux personnes avec des compétences et des points de vus divergents, les détails techniques d'un OS ce n'était pas tellement du ressort de Jobs qui s'en fichait probablement.

Torvalds a surtout été contre Tanenbaum à ce sujet, mais là encore il ne semble pas que Torvalds soit fondamentalement contre les micro-noyaux en tant que tels, juste qu'il ne croit pas que ce soit la solution parfaite et universelle que soutenait Tanenbaum à l'époque et qu'il méprisait toutes les autres architectures malgré les avantages et inconvénients de chacun.

C'était aussi un bon développeur qui a activement participé au développement de la micro informatique. Et selon quelques employés de Microsoft dans les années 90, Gates était toujours compétent techniquement à ce moment là.

Bien sûr que Gates a aussi eu de bonnes idées pour se développer commercialement, mais contrairement à Jobs il était aussi bon techniquement ce que Torvalds savait. Il y avait donc matière à discuter d'égal à égal ce qui l'intéressait plus que les plans de Jobs qui étaient plutôt commerciaux. Ce qui n'est pas son centre d'intérêt.

Ce que je voulais souligner c'est que contrairement à ce que pensent beaucoup de personnes dans le milieu du libre, Torvalds n'est pas anti Microsoft primaire et a toujours eu un certain respect pour Gates. Donc qu'il se rencontre n'est pas surprenant, c'est d'ailleurs plutôt étonnant que cela n'ait jamais eu lieu plus tôt.

Dans sa biographie de 2001 (et oui ça date), Torvalds relatait qu'il avait rencontré Jobs qui souhaitait former avec lui une alliance contre Microsoft et Windows ce qu'il n'a pas souhaité faire. Il trouvait qu'il n'avait pas grand chose à voir avec Jobs qui était plus dans le domaine du marketing que dans le technique et qu'à contrario il trouverait sans doute plus intéressant de discuter avec Gates qui est à la base un développeur expérimenté.

À dire vrai Gates et Torvalds ont clairement des cheveux blancs depuis longtemps, cela n'a rien de nouveau cela fait plusieurs années qu'on les voit comme ça.

Par contre Gates a pris un sacré coup de vieux depuis des images récentes d'il y a 1 an. Torvalds semble moins affecté par le temps à ce stade.

Bon il y a quand même 14 ans d'écart entre les deux hommes. Mais les débuts de la micro informatiques ça commence à dater, tout ce petit monde devient vieux et finira par partir de ce monde aussi.

Malheureusement, tu as tout compris : les tickets pour assister à de nombreuses conférences sont souvent payées par un employeur. Il faut être vraiment passionné (et avoir un bon salaire) pour se payer un ticket à titre individuel.

Après vu le tarif, même sans être payé par l'employeur c'est plutôt abordable en fait d'autant que la nourriture et boisson (petit déj, goûters, repas du midi) sont compris dedans.

De toute façon quand l'événement est en semaine c'est souvent orienté entreprise et vu le niveau technique de la conf c'est en effet plutôt pour des pros qui bossent de près ou de loin sur ces sujets.

Néanmoins, à part cas particulier, ces tarifs sont justifiés étant donnés les coûts d'organisation : location d'une salle pour X jours, repas, éventuellement traiteur pour buffets, défraiement pour voyages et hébergement des speakers…

En plus les participants sont pour beaucoup d'une grande renommée, très sympas et accessibles, beaucoup viennent de loin pour ça et pouvoir leur parler librement entre deux croissants, c'est vraiment chouette.

Personnellement venir à Kernel recipes (et Embedded recipes quand c'était commun) est sans doute la meilleure expérience de conf que j'ai connu. Même si je ne pourrais pas venir cette année malheureusement, je compte bien y retourner. :)

Et encore merci à Anne (et à ses petites mains) pour l'orga. Toujours une chouette expérience.

Seulement pour les fonction C standard. Et cela se justifie par le fait, qu'elle sont plus simple à mémoriser et plus rapide à écrire.

C'était surtout une limitation des compilateurs de l'époque.

Rien ne t'empêche de compiler avec la config par défaut ou celle fournie par ta distribution.
ela n'a pas forcément beaucoup d'intérêts de le faire ainsi on est d'accord mais c'est très simple.

sur le premier lien, on lui reproche grosso-modo de casser l'ABI du code présent dans la branch main, parce que des gens utilisent directement cette branche, faute de nouvelle version de Xorg depuis 3 ans. Alors si on ne peut pas modifier l'ABI dans cette branche, on le fait où ?

Au hasard dans une branche dédiée qui rejoindra main quand ce sera le bon moment de faire une nouvelle version par exemple ?

Je vais vraiment commencer à croire que les défenseurs veulent réellement pouvoir truquer les résultats.

Mouais, suffit de parler à pas mal de gens qui n'ont pas réfléchi à la question que ce soit des personnes ayant un bagage techniques ou pas et tu constateras que les préoccupations concernant la sincérité du scrutin ou de manipulations du dit scrutin sont écartées bien facilement. Même en expliquant le soucis.

Donc je ne suis pas convaincu que leur entêtement prouve quoique ce soit à ce sujet. C'est peut être le cas, mais sans doute pas.

C'est, à priori, unidirectionnel donc l'émetteur ne sais rien des récepteurs mais est-ce que le vol ou la saisie d'un poste de radio pourrait donner des informations sur l’utilisation du récepteur ?

Rien n'empêche un émetteur radio FM de logger cette information, tout comme un récepteur radio DAB+.
C'est indépendant de la techno ce que la machine fait localement à des fins d'interface utilisateur ou de débogue.

Mais dans les deux cas, (comme les satellites de géolocalisations ou la télé hertzienne / TNT) le flux est en effet unidirectionnel. Sinon ça ne tiendrait pas la charge.

L'autre problématique rarement évoqué sur ce sujet est la confidentialité.

Utiliser un LLM dans son coin pour son boulot qui est en ligne et non avalisé par son employeur, cela signifie que tous les échanges sont normalement monitorés par l'entreprise fournissant le dit LLM.

Ce n'est pas terrible alors que dans le lot il peut y avoir des données plus ou moins sensibles, que ces échanges et donc le code et ces éléments peuvent servir de base d'entrainement et donc éventuellement ressortir plus tard. Etc. Dans un contexte pro c'est vraiment un problème.

Je doute que tout le monde fasse attention à cela dans ce contexte…

La question du droit d'auteur n'est semble-t-il toujours pas tranché à ce jour non plus.

Cet article présente des arguments qui font sens et d'autres beaucoup moins. Et c'est dommage de mettre les défauts et problématiques réels sous le tapis, même si je peux comprendre sa frustration face à certains arguments, il ne faut pas oublier ces éléments non plus.

Cet article comme beaucoup d'autres qui parlent du cas Islandais évoquent beaucoup de semaine de 4 jours mais il semble bien que ce soit trompeur.

D'après ce qu'on peut lire dans cet article comme ailleurs, c'est avant tout une réduction de 40h à 36h de travail hebdomadaire pour un temps plein. Comme apparemment les jours travaillés ne sont pas plus longs, c'est donc plutôt un 4,5 jours de travail par semaine. La réduction du temps de travail est donc plutôt de 90% que d'un 80%.

D'ailleurs une rétrospective de l'étude initiale pour cette expérimentation ne parle pas de semaine de 4 jours : https://autonomy.work/wp-content/uploads/2021/06/ICELAND_4DW.pdf

Et de fait les Islandais travaillent en théorie plus que les Français à temps plein malgré ce dispositif. Cela ne permet pas de conclure donc le résultat si on passait par exemple à 32h même si une partie des bénéfices devraient être augmentées encore.

D'ailleurs je me demande ce qui serait le mieux dans ce cas de figure : rester à 4,5 j de travail pour 36h (donc 8h par jour les journées complètes) ou passer à 4j de travail avec 9h de boulot ? Honnêtement je ne saurais dire ce que je préfèrerais.

Pour ce qui concerne les comparatifs entre différents contrats, la conso totale et moyenne suffisent, non ? Ces infos sont déjà sur les factures ou les résumés par années.

Pas forcément, cela peut te permettre de savoir si c'est intéressant de passer à un forfait mono horaire à bi horaire (ou plus, à l'avenir cela se développera) ou à des offres plus complexes comme Tempo.

Sans granularité la comparaison sera très imprécise en particulier si tu as une consommation électrique très importante (chauffage / eau chaude électrique, voiture électrique, cuisinière et fours électriques, etc.)

La facture est trop succinct pour un comparatif fin et à l'avenir cela va devenir encore plus nécessaire avec els projets de tarifications encore plus flexibles.

Ce n'est plus lire entre les lignes si le rapport est externe. ;)

En fait, je vois pas ce que la date change au profil du monsieur. La cause de de ton désintérêt est peut-être ailleurs.

Disons qu'il se passe des choses en 7 ans, cet article n'apporte pas grand chose par rapport à Wikipedia par exemple.

Le fait que ce soit un lien Le Monde fait penser que récemment un truc est arrivé le concernant justifiant un tel article. En fait non.

Je connais vite fait le monsieur donc en effet une petite bio ne m'a pas apporté grand chose. Je pensais qu'un article de leur part parlerait plus d'actualité.

Alors avec ton commentaire je comprends ton but mais honnêtement je n'avais pas fait le lien et je doute être le seul.

Je ne dis pas que ce n'est pas faisable ;)

Je pense en effet que le cahier des charges devrait gérer facilement une année glissante de données accessibles.

Ce que je remets en cause c'est la thèse que ça ne sert à rien comme limitation. Il y a sans doute une question de coût derrière qui est réel.

De l'autre côté, on veut pouvoir exporter ses données, Next parle de 20 000 lignes pour un an, chaque ligne contenant 2 dates (c'est un intervalle) et une valeur flottante en kWh, 3 chiffres après la virgule. La quantité de données retournée est donc ridicule. Évidemment, la base derrière est plutôt conséquente, mais je serais assez surpris que ça ne soit pas à la portée d'une belle grosse machine.

Je ne connais pas l'infrastructure d'Enedis. Ni où c'est hébergé, ni comment les données sont structurées.
Mais dans mon boulot on fait des opérations finalement proche d'un Linky dans l'industrie mais avec un pas de 1 minute environ.

AWS oblige, à partir de 3 mois c'est archivé dans une BDD différente en stockage froid car c'est significativement moins cher. Et réduire la taille de la BDD au global car la partie active n'a que trois mois d'historique permet de réduire la taille de celle-ci évidemment et améliore de fait les performances et donc les coûts à tous les étages (stockage + CPU + mémoire).

Cela ne m'étonnerait pas que le volume de données sur l'ensemble de la France implique des compromis de ce style. Techniquement ils pourraient le gérer, mais probablement trop cher en open bar donc ils mettent des restrictions.

Pour moi c'est en effet regrettable de restreindre autant, je pense que les 12 derniers mois facilement accessibles devraient être requis pour des raisons de facturation et de comparaisons tarifaires. Au delà éventuellement si c'ets plus chiant…

L'article date de 2018, je ne comprends pas l'intérêt de déterrer un si vieil article qui ne nous apprend pas grand chose par ailleurs.