Jean Gabes a écrit 467 commentaires

J'avoue que l'annonce a le mérite de ne pas tourner autour du pot, et dit clairement les choses, et contre qui elle est dirigé et pourquoi.

Après on aime ou pas sur le fond, et on va revenir sur les mêmes débats ("y en a qui y arrivent avec tel modèle, pourquoi pas eux?", "eux n'ont pas les mêmes compétiteurs, donc non ça marche pas le modèle classique", etc), mais là faut avouer qu'au moins on ne peut pas dire qu'on ne sait pas pourquoi.

Je plussoie. Si c'est ouvert, mais que tu n'as aucune activité autour, ça pourrait tout aussi bien être fermé car tu n'as aucun intérêt à partir dessus sauf à gagner du temps en R&D initiale, mais par contre tu vas devoir assurer 100% de la R&D par la suite.

Là où le but est quand même de diminuer le coût de ta R&D, donc la partager (pas de magie, faut bien que certains paient :D ).

Dans les faits oui, mais si tu as à faire à un client très galère, ça se fini en guerre de juriste, et là la GPL ne va pas être ton amie car justement trop d'interprétations.

Le "oui mais ça n'arrivera pas", n'est pas un argument quand tu dois proposer une lib à un CTO. Il ne prendra pas le risque, et prendra la MIT à la place, même si ça doit lui coûter un peu plus cher (après si ça lui coûte un bras, il prendra le risque, mais on parle bien de ça: un risque, et un risque légal, donc très dangereux en cas d'audit and co).

Il semblerait que la SEC s'intéresse de prêt au mécanisme de dividende, avec l'imposition qui va avec: https://journalducoin.com/ethereum/ethereum-2-0-a-peine-ne-deja-menace-la-sec-prete-a-la-guerre/

Tu parles d'une tablette, mais as-tu essayé une liseuse (à encre donc). C'est vraiment pas le même confort.

Je n'arrive pas à lire un gros article sur une tablette, mais je dois bien avoir 2000h au compteur sur ma kobo :)

Je suis plutôt d'avis de penser que ça ne les regarde pas trop, si, et seulement si, on parle bien d'une IA qui comprends/apprends des patterns pour les reproduire dans d'autres contextes.

Je m'explique: déjà en mettant le code sur github, tu les autorise à le lire, pas forcément le redistribuer tel quel, ou en faire un travail dérivé (sauf si c'est MIT/BSD, là bon faut être de mauvaise foi pour refuser l'exploitation de son code je trouve).

Mais je pense que si on a bien une IA qui apprends comme on le ferais nous sur:
* comprendre un commentaire pour savoir ce que ça fait et pourquoi ça le fait comme ça
* quelle est la meilleure structure de données pour faire telle opération
* pourquoi le code dans tel langage doit être agencé de telle manière

C'est un peu comme un débutant qui va travailler chez Capgemini/Atos/AUTRE-SSII: tu ne vas pas lui reprocher plus tard de savoir écrire du code car il a appris sur des systèmes fermés développé pour telle ou telle société du CAC40? (oui je tire le trait exprès :) )

Si on parle bien d’apprentissage, le code généré n'est pas lié au code lu, seulement à l'apprentissage du langage et de sa logique.

Bon maintenant le vrai éléphant dans le couloir: comment on sait que c'est du vrai apprentissage et pas juste des copier/coller un peu malins? Car là en effet ça pose problème avec les licences vu que ça serait un travail dérivé.

Insolvable?

Enlever les Maths, rajouter du Python, why not :p

En tout cas ça va fortement jouer en sa faveur pour les nouveaux projets. On est toujours un peu attaché à son premier langage (ah mon cher C, ce qu'on a pu se détester mutuellement, moi avec des insultes sur gdb, toi avec des segfaults).

Ce n'est pas un mauvais choix en tout cas, Python a quand même été pensé au tout début pour des débutants. On peux encore faire des choses simplement avec.

Je vois qu'on a eu les mêmes chefs de projets :p

Pour la compilation de Python, il me semble que la plupart du temps c'est surtout un interpréteur embarqué qui se lance facilement (donc grosse boite noire), mais donc avec tout son volume. Après il y en a peux être qui "compilent" vraiment, mais pour du Python générique (non modifié pour) j'en vois pas.

Tout à fait d'accord que de toute manière ces langages ont atteint un tel poids dans l'historique, qu'ils ne vont pas disparaitre comme ça. Mais dès qu'il y aura une contraite (légale, sécurité, "plus de dev/trop cher") là ils seront remplacé par le standard de l'industrie à ce moment là (qui deviendra lui même obsolète, cycle éternel et merveilleux :D )

L'argument de la sécurité est valable en tout cas. Quand on voit l'enfer d'audit des dépendances en cascades, moins de langages ne serait pas un mal. Après mêmes les langages compilés sont touchés, juste que les dépendances sont bundlelisées et pas ultra-visibles comme sur python/node/XXX.

Mais là encore: est-ce que notre très cher (double sens) chef de projet a plus d'intérêt (€) à faire un projet rapide qu'un projet blindé/audité/maitrisé? Pour l'instant je n'ai pas l'impression qu'on va dans ce sens pour une majorité (je mets de côté les industries où c'est le légal qui l'impose, genre aérospatial, etc).

Or même avec les derniers soucis majeur en terme de sécurité sur la chaine, j'ai pas l'impression que les habitudes aient tellement changées. Jusqu'à la prochaine faille exploitable à distance dans un module standard? :p

Vrai, mais là tu te places sur le terrain du purement technique ou de l'ultra embarqué (où chaque Mo compte).

Si tu prends dans un plan plus global/standard, quelques Mo ça ne compte juste pas dans l'équation. Ni d'ailleurs en quoi sont fait les outils (je me fiche bien de savoir que tel outil est codé en perl tant que la distribution gère les dépendances comme il faut).

Si tes points sont tout à fait valides sur les chiffres, mais quand je démarre un projet ce ne sont pas des questions que je me pose. Les Mo et l'empaquetage, on y arrive, c'est jamais un vrai soucis (ça prends juste du temps qu'il faut compter, point), sauf grosses exceptions (ultra embarqué).

Par contre je me demande comment je vais réussir à faire travailler X développeurs ensemble, et comment je peux trouver les compétences pour. Or sur ces deux plans Perl perds.

Là on en arrive à la philosophie du langage et à son image dans l'industrie (le premier influe le second dans le temps).

Déjà que faire travailler du monde ensemble en Python c'est pas facile, mais en perl c'est une autre paire de manches (la philosophie du langage l'implique directement). Et trouver du monde employable pour Perl est … heu… disons ultra complexe. C'est déjà un peu plus jouable en Python même si c'est tendu.

C'est pas pour dire que tes points sont faux, pas du tout, ils sont tout à fait juste techniquement, juste que d'un point de vue d'un chef de projet, ils ne comptent pas cher dans son équation.

Or c'est bien eux qui sont au manettes désormais, plus les petits artisans qui souhaitent que tout soit cohérent. Eux veulent juste que ça soit "gérable", peux importe la cohérence technique sous-jacente. Chacun ses contraintes, mais eux ont le financement :p

Sans troll quelconque malgré le jour, la question se pose vraiment à l'heure actuelle. Le postulat de "je peux faire comme je veux" est le contraire de l'industrialisation.

Perso j'ai tendance à aimer ce genre de postulat, qui ne te bloque pas dès que tu veux sortir un peu des chemin battus. Mais il faut bien avouer que c'est plutôt de l'artisanat ou alors seulement des cas bien particuliers.

Mais dans une industrie (traduire: avec gros travail d'équipe), "un tel va faire comme il veux, peu importe pour les autres", ça marche pas longtemps.

Après bien sûr qu'il y a le poids de l'histoire, le langage ne disparaitra jamais. Mais de là à attirer de nouveaux projets en masse, je ne pense pas.

C'est en effet un autre signe d'une industrialisation grandissante de notre domaine.

Mais ça risque d'avoir les mêmes effets que systemd sous linux: la majorité va l'accepter sans trop rechigner, mais les artisans (sans le sens de l'"art") vont y voir une barrière supplémentaires et une perte de contrôle.

Un bien ou un mal, je ne suis pas juge là dessus.

Le vrai souci c'est que ce genre de mécanisme tu l'as sur ton lieu de travail (ce qui est totalement justifié), mais si on te le mets sur ton hobby, tu fais le lien entre les deux, et là, bye bye le côté hobby, tu retrouves dans le mindset du boulot, sans la récompense extrinsèque par contre ^{^}

On va me dire que l'on a aussi ce genre de mécanisme d'authentification dans steam et cie, mais quand je joue, mon cerveau ne fait pas de comparaison avec le travail, alors que quand je code, le risque est bien plus grand :D

Je suis plus d'avis qu'on a seulement plus d'informations là où avant c'était limité à un cercle d'informés. Je pense que ce sentiment est aussi valable pour une bonne partie des problèmes de la sociétés: plus on a d'infos, sans filtre ni analyse profonde des causes/conséquences, plus on va avoir ce sentiment je pense.

Par exemple dans notre cas, ceci va mettre des informaticiens/informaticiennes sur le marché avec, je l'espère, pas mal d'aides pour des formations et des fonds pour rechercher sereinement, et certains vont pouvoir être recasés dans autre chose qu'une SSII, ce qui de mon avis personnel est une bonne chose pour l'écosystème français dans son ensemble.

D'où le terme de "sauvegarde de l'emploi" qu'il faut voir de manière globale, pas du point de vue d'une société qui n'est pas rentable (ou pas "assez" rentable, mais ça c'est un autre problème qui je pense est le vrai souci de l'économie actuelle).

C'est exactement ça, une question d'équilibre. Ensuite perso je préfère un code plus simple à lire qu'un code simple à tester.

J'écris le test une fois, je le lis des dizaines de fois :D

Et là encore, il faut un certain équilibre (le test reste du code, qu'il ne faut pas sacrifier).

En fait dès qu'on me parle sous la forme d'un dogme ("les commentaires ne servent à rien, le code doit se suffire", "une fonction ne doit pas dépasser 5 lignes", …) j'arrête l'échange car ça ne mènera à rien si on ne parle pas de cas concrets (viens sur la couche système/réseaux sans commentaires et on en reparle :D).

Après ça vient avec l'expérience, c'est facile de dire ça après près de 20ans de code (purée déjà :p), et qu'au début il faut quelques recommandations à suivre.

Mais il faut bien comprendre que ce sont des recommandations et que tu dois les remettre en questions face à une situation.

Bon vu que les articles sont désormais ultra polarisés pour attirer le chaland, cette notion n'est pas vendeuse, et on est donc pas sorti de l'auberge :(

Le rachat remonte un peu, si vraiment c'était un choix purement vertical sans considération du terrain, ça fait un moment qu'ils l'auraient tués sans pitié (coucou Centos).

Je pense plus qu'à concurrence égale, il n'avait plus d'intérêt face, notamment, à une solution en "interne", et sans attractivité d'une grosse masse d'utilisateur, il doit mécaniquement fermer.

Ils ont pris le risque de ne pas faire un standard afin de faire un écosystème performant, mais fermé. Si c'était aussi bien et en avance, pourquoi ne pas en faire une norme, ils étaient déjà en avance.

Mais non. Ils le paient quand il y a une force politique pour protéger l'intérêt général. Dommage de devoir en arriver là par contre.

Ça serait bien de l'appliquer au cloud d'ailleurs (réelle réversibilité contre l'enfermement).

Note: je n'ai rien contre l’innovation et le fait de gagner le fruit de ses recherches, sauf quand elle a pour objectif de contourner les lois de marchés en enfermant un client dans un écosystème. Et non, enfermer un client n'est PAS normal/acceptable peu importe la qualité du produit/offre. Ce n'est pas tenable sur le long terme pour l'économie.

Bah… git lui même.

Je ne comprends pas la question en fait.

C'est jouable de passer des valeurs d'un check à un autre dans nagios/shinken/icinga and co, mais après ça peux te poser des contraintes lors de la scalabilité et c'est pas trivial (pas de magie :p ).

Donc le principe d'avoir un check qui fait la vérification de toute la chaine est valable, car vérifier juste que SMTP et IMAP répondent n'est pas suffisant dans la vraie vie.

J'avais un script mode "a l'arrache" dans le passé qui faisait ça, mais clairement en faire un vrai projet a un intérêt :D

Surtout que les contrats et pactes d'actionnaires sont là pour gérer ce genre de cas, et il faut le prévoir à l'avance les cas de divorces (c'est même une grosse partie des pactes).
Tu ne peux pas changer les règles a posteriori car ça ne te va plus.

Mais ce qui m’embête c'est également que la télémétrie peux bloquer le navigateur. Il pourrait exploser en plein vol qu'il ne devrait pas impacter le reste à mon sens.

Ça s’appelle la balance bénéfice/risque, comme pour n'importe quel autre médicament/traitement.

Sauf preuve du contraire (sourcés) on a quand même plus de chance qu'il nous aide en cas de contamination (qu'il n’empêche pas, ça serait l'idéal mais on ne l'a pas ce choix pour l'instant, donc ça ne rentre as en compte dans l'évaluation) que de risque en lui même => piqure.

Est-ce que chez certains ça a été inutile car ils s'en seraient sorti sans? oui.
Est-ce que chez certains ça va rendre malade (vaccin qui réveille ton système immunitaire, ça fait pas du bien par définition)? oui.

Est-ce que la médecine est une science dure/exacte à 100%? certainement pas, mais elle fait au mieux avec ce qu'elle a (des humains qui ne sont pas 100% identiques, et qui donc réagissent plus ou moins bien aux traitements, il y a encore trop de facteurs en jeu/inconnus pour qu'on arrive à le prévoir autre que par des tests/statistiques).

Est-ce qu'on aimerait bien une médecine parfaite qui arrive à prévoir par individu ce qu'il faut faire? Oui, mais spoiler, aucun de nous n'en verra la couleur dans cette vie je pense vu la complexité de la problématique :D

Question: le rachat est-il uniquement pour remplir le XBox pass et tuer la concurrence de Sony sur le créneau, ou c'est un peu plus vaste que ça et avoir à sa disposition des éditeurs qui savent créer/gérer/exploiter des univers en 3d pour autre chose que le jeu? (genre faire un concurrent du metaverse de FB)?

De mémoire le XBox pass c'était encore en phase d'investissement avec de grosses pertes (jusqu'au jour où ils ont le monopole et hop bonjour la vache à lait). Mais avec un investissement de cet ordre de grandeur ça creuse encore le trou (pas qu'ils ne peuvent pas se le permettre après tout).

Après si eux ne le rachètent pas, ils ont un risque qu'un autre le fasse (Amazon?) et perdre une partie de leur investissements passés.

Bref, même en mettant de côté les affaires internes glauques d'Activision, ça laisse encore pas mal de questions sur ce qu'ils vont en faire.

Surtout penses à tes pilules, les bleues ou les rouges, au choix ;)

J'avoue que je suis plus de l'avis de l'auteur du journal, mais suivant la situation.

Si je me place dans mon cas, donc dans un contexte d'éditeur, il n'y a pas de différence entre ce qu'on code et ce qu'on livre comme dépendances, le seul élément qui compte c'est le livrable final, tout ce qu'il y a dedans est de notre responsabilité, d'où le fait qu'on ait une attention ultra haute sur les dépendances. Ça a un énorme coût temps/humain, mais c'est le métier d'éditeur qui veut ça.

Mais dans une situation de service peux être qu'on peux faire différemment et avoir une autre relation avec son client. On peux juste lister au client les dépendances nécessaires, et que c'est à lui qui prends cette partie à sa charge. Le prestataire pourrait le faire, mais avec un surcoût important (point de magie), ce qui fait que le client va le gérer lui, et juste mettre à jour/revert en cas de problème que lui détecte (mais c'est de la gestion interne, qui n'a pas vocation à avoir de facturation).

Est-ce que ma vision est correcte ou bien en fait c'est beaucoup moins marqué que ça?

Merci :)

Je ne dis pas que c'est une mauvaise distribution qui ne fonctionnera pas techniquement, mais le problème n'est pas technique justement.

C'est juste qu'il est impossible de dire "production" sur Centos Stream au client final (lui retient que c'est avant RedHat qui lui est stable/production), donc c'est forcément moins stable (peu importe la réalité de sa stabilité).

Tout n'est qu'une question d'image ici. Stream peux avoir toutes les qualités possibles, son image est:
* centos8 a été avorté en terme de support, donc manque de confiance envers RedHAt sur le sujet après pour ce qui concerne autre chose que RHEL, Stream en hérite automatiquement,
* c'est avant la RHEL/production dans son workflow, donc c'est instable/qualification. Basique.

Et c'est bien ce que souhaite RedHat je pense, qu'on arrête d'avoir une distribution "production" gratuite (qu'en plus lui paie ^). C'est réussit :)

Switcher sur Rocky ou bien Alma? :D