Jean Gabes a écrit 433 commentaires

Compliqué pour un particulier, mais pas pour leurs vrais concurrents je pense. Donc d'un point de vue business, c'est logique.

Après elle a peu être accès à des docs internes qui disent clairement: "si elle commence à avoir conscience d'elle même, on la coupe", et alors elle ment :)

J'avoue avoir du mal à voir du Trump pire que du Trump tellement il est une face. Je pense qu'il est l'expression parfaite à son paroxysme, pas la peine d'en rajouter.

Et si Neo est "après", bah par définition le Trumpisme n'a pas d'après et ce peu importe dans quel camps on se place :)

Vraie question est: dans leur modèle qui paie (ou développe) la maintenance? Car ça reste ce qui coute le plus cher dans la vie d'un logiciel au final.

C'est le point que je trouve bien traité dans l'article justement. Il insiste bien là dessus, que certains clients ne veulent payer que pour les nouvelles fonctionnalités, mais pas ce que ça demande comme correction adaptation sur les anciennes pour que ça reste maintenable dans le temps et qui fait qu'un modèle purement de service n'est pas viable techniquement sur le long terme (quand on parle d'outils, pour les libs le souci n'est pas exactement le même).

Quand on souhaite ranger. Et c'est bien là le premier hic je pense. Beaucoup de personne que je rencontre souhaite laisser cette tâche (faut avouer, c'est tout sauf marrant) à l'appli qu'elles utilisent.

Bien souvent je ne les vois pas rechercher puis ouvrir un donc mais lancer l'application et là retrouver le document (dans les derniers ouverts par exemple). L’hégémonie des téléphones n'arrange pas les choses de ce point de vue :(

N'utilisant pas Java, je n'ai rien à dire sur le fond, par contre bravo pour la forme, ce journal Énée très bien écrit.

J'étais étudiant qu'on en parlait déjà comme de la nouveauté qui va tout changer. Quasi 20ans après, toujours rien, alors que le défi n'est pas technique en fait (accrocher des tags sur des objets avec un langage de requétage, ça va on sait faire).

Je pense qu'en fait c'est surtout utile pour une partie de la population, qui arrive à penser de cette manière là (et qui y voit un gain important dans l'organisation et la recherche en effet), mais je pense que la majorité des personnes ayant déjà du mal à ranger dans des "répertoires" (qui sont juste des tags mais genre un seul par objet au final), tu ne va pas réussir à leur mettre X tags par objets. C'est juste trop confusant pour eux.

Bref, on en reparle dans 20ans je pense :)

Merci,

En effet, ça peux être un moyen de tester des gestions sans avoir à attendre toute la validation en natif dans le(les) moteur(s).

Après une fois que c'est validé/normalisé, mieux vaut à n'avoir à télécharger son navigateur qu'une fois avec le natif inclus, et pas 300K à chaque page.

On a une idée du gain natif/WASM sur ce genre de cas qui est purement calculatoire?

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