Jean Gabes a écrit 374 commentaires

J'aimerai bien savoir quel est le pourcentage de personnes encore présentes chez Twitter qui n'ont juste pas le choix à cause de leur visa de travail, et qui cherchent activement autre chose le temps de pouvoir quitter Twitter sans devoir quitter le pays.

Après nul doute qu'il a un plan pour Twitter, et qu'il ne jettera pas à la poubelle 44M$ comme ça. Mais ayant fuir les marques, le plan du Twitter-Paypal est pas déconnant en effet, surtout vu le pédigrée du mec, et que le modèle marche déjà ailleurs avec succès.

C'est quoi un "soft-fork" exactement? Un fork c'est un fork non?

Dans tous les cas les codes vont diverger et les utilisateurs vont devoir choisir in-fine lequel des deux prendre.

Sur le fond, comment se passe dans les cas où on a fondation + société commerciale, genre Firefox, en ce qui concerne la "marque"?

La marque reste un objet "commercial", seul le code est open source. On retombe dans le cas classique de la marque qui n'a pas été gérée clairement et qui pose problème quand les $ arrivent.

Je ne m'avance pas pour dire qui de l'un ou l'autre devrait avoir la marque. Dans le cas commercial, bon courage pour se lancer sans la marque, c'est quasi mort né s'ils la lâchent ou ne peuvent pas l'utiliser librement, mais la fondation ne sera pas libre si elle ne l'a pas. D'où ma question de savoir ce qui est fait d'habitude dans le domaine.

Pas faux factuellement, mais trompeur. Dire qu'ils passent de Centos à Rocky c'est beaucoup moins vendeur que RHEL à rocky.

C'est pour les 3.0.X et plus, donc la majorité des systèmes ne sont pas impactés, ouf :)

J'avoue, elle est pas mal :)

S'il y a bien une expérience qui mets à mal notre compréhension de l'univers, c'est bien celle là :)

Je ne comprends pas. Là si justement, vu qu'ils laissaient les libertés à tous le monde par rapport à eux même, tout le monde étaient au même niveau côté compétition (modulo les moyens de chacun, qui fait la réelle différence au final quand on pars d'un même point).

Ou alors il y a une subtilité que j'ai raté, ce qui est possible :)

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.