Le 12/10/2020 à 10h 45

Je suis un peu sceptique aussi, même si dans le fond je trouve que le découplage a du sens.
Mais si c’est bien régulé par l’État / l’Arcep, pourquoi pas.

Le 12/10/2020 à 10h 34

David_L a dit:

Les discussions stériles pour savoir si des langages comme C et C++, etc.

Ah oui sur le côté stérile en tout cas, rien à redire! 😁

Le 12/10/2020 à 08h 39

J’ai pensé la même chose, je vois plutôt la notion de langage compilé versus bytecode/interprété entre ces groupes, mais pas bas/haut niveau qui est plus une affaire d’abstraction dans le langage lui-même et non dans son runtime.

Le 12/10/2020 à 08h 36

Waw! Bravo et j’admire le courage de lancer une série sur Rust, ce n’est pas le choix de la facilité! :-)

C’est pas le premier langage auquel on pense pour apprendre … D’un autre côté, ne pas avoir l’habitude d’un autre langage, habitudes qui peuvent s’avérer contre-productives en rust, peut-être que c’est un atout.

Le 18/09/2020 à 09h 04

Voilà qui ne va pas améliorer le bilan carbone de leurs datacenters… :-(

Le 22/08/2020 à 06h 31

Écrire du yaml

Le 21/08/2020 à 22h 18

Même pas dans mes pires cauchemars 😅

Depuis git, tous les cvs/svn/clearcase/sourcesafe/… => poubelle. C’est vraiment un des rares domaine où il y a un tel consensus.
Le seul concurrent qui apparemment trouve grâce auprès de certains, ce serait mercurial. Mais perso j’ai jamais utilisé.

Le 21/08/2020 à 22h 07

Bel article!
GIT… Perso, c’est de loin l’outil qui a le plus amélioré mon quotidien de developpeur depuis que je bosse. Impossible de revenir en arrière une fois qu’on y a pris goût.

Le 20/08/2020 à 13h 12

Ben en tout cas félicitations d’être allé jusqu’au bout et d’avoir persévéré. C’est vrai qu’il y a parfois de quoi se décourager.

Le 20/08/2020 à 09h 57

fofo9012 a dit:

Ma plus grosse contribution est sur ffado (pilote linux pour les cartes son et platine firewire) j’ai tout migré de python 2.7 à 3 et de QT4 à QT5, mis à jour tous les composants qui étaient obsolètes, corrigé des tonnes de warning à la compilation, refais l’interface du mixer. À défaut d’accès SVN, j’ai envoyé le patch (~1 / 2mo de code sources quand même) au dev était content, a tout analyser et décortiquer, il a fallu que je justifie chaque changement par mail (genre expliquer que QT4 ou Python 2.7 était désuet), il n’a pas tout repris, donc il reste tous les warning C++ sur des pointeurs inadaptés, et l’interface graphique est restée avec ces soucis d’ergonomie…

Je pense que c’est un excellent exemple de frictions qu’il peut y avoir. Peut-être que si tu avais eu à ce moment quelques bons conseils, ça ne se serait pas passé comme ça? C’est très risqué en effet de partir sur un gros refactoring. Dans ce genre de cas je pense qu’il faut établir la communication bien en amont, pour avoir l’avis du mainteneur avant de rentrer dans le vif (peut-être l’avais-tu fait?). Parce que évidemment, passer un temps fou pour quelque chose qui sera refusé, il n’y a rien de plus dégoûtant. Dans ton cas, apparemment plein de choses ont été gardées donc c’est plutôt une réussite, même si ce ne fut pas simple. En général on essaie de faire des patchs focalisés sur un point précis pour éviter de s’exposer à trop de problèmes “secondaires” (autrement dit, pas tous les oeufs dans le même panier).

Même si je comprends cette frustration, il faut aussi se mettre à la place du mainteneur : un inconnu déboule et propose des tonnes de changements (je caricature, ça ne s’est peut-être pas passé exactement comme ça). Il y aura forcément un peu de méfiance au premier abord. Ça peut prendre du temps de comprendre exactement le use-case qui exige ces changements. Aussi, le contributeur en général ne pense qu’à son propre use-case, alors que le mainteneur est garant de la cohérence de l’ensemble et ne doit pas perdre de vue peut-être une myriade d’autres situations. Il y aura certainement des points qui peuvent vous paraître anodins mais qui seront critiques pour le mainteneur. Si le mainteneur a un haut niveau d’exigence, c’est peut-être rebutant pour des premières contributions, mais c’est peut-être aussi un gage de qualité pour le projet. Dans le cas que tu cites, avec les warnings du compilo, peut-être que tu as raison mais (désolé) on ne peut pas juger sans avoir l’autre son de cloche.

Quant aux pull-requests en général ça s’accompagne d’outils de code-review qui justement permet de fluidifier les échanges entre le contributeur et le mainteneur.

Le 20/08/2020 à 07h 23

Je ne pense pas qu’il faille inputer ça à l’ego des développeurs (ça doit arriver mais assez rarement, enfin j’espère) à mon avis c’est encore et toujours une question de moyens, trop de volume de travail par rapport aux ressources, alors forcément les rapports de bugs s’empilent, et les moins impactant passent à la trappe. 😔

Le 19/08/2020 à 15h 37

C’est totalement vrai, être développeur open-source demande aussi d’avoir des compétences de dialogue et d’écoute que malheureusement tout le monde n’a pas (ce qui n’en fait pas de mauvais codeurs) :-( Il faut voir qu’en faisant de l’open-source, on se voit cumuler plusieurs métiers genre développeur - support technique - relation client - marketing , et la plupart du temps il n’y a pas les ressources pour mettre 1 personne sur chaque rôle.

Le 20/08/2020 à 07h 12

(reply:1821429:le hollandais volant)

Maintenant le challenge c’est de générer cette même somme par leurs propres moyens. Pas sûr que 3 ans suffisent, et pas sûr que google continue la perfusion dans 3 ans… J’imagine que c’est un peu ça, la raison des licenciements.

Le 19/08/2020 à 15h 29

VSCode a su générer un énorme écosystème de plugins qui le rend attractif bien au-delà de ça. Je le vois utilisé pour du JS, du Go, du Rust, même du Java. Après, les goûts et les couleurs bien sûr …

Le 19/08/2020 à 14h 14

Alors, disclaimer ça fait des lustres que je ne l’ai pas utilisé, mais comme ça je dirais, la lourdeur / conso mémoire / temps de démarrage ? (Comparé à vscode)

Le 19/08/2020 à 14h 11

J’imagine que ça fait partie des changements depuis l’ère Balmer, MS lâche la bride à ses ingénieurs qui du coup, avec une plus grande autonomie qu’avant, peuvent innover là où on ne les attend pas. Ce qui donne peut-être une stratégie d’ensemble moins homogène et des divisions qui peut-être, parfois, entrent en concurrence comme TypeScript / .NET. À un moment on se rend compte que la concurrence est bénéfique et que tout n’est pas qu’une histoire de parts de marché.

Le 10/08/2020 à 10h 21

Commentaire_supprime a dit:

C’est intéressant pour le noob que je suis.Si j’ai bien compris l’esprit du service, cela consiste à proposer au client la “plate-forme” en dur, avec le maximum de fonctions élémentaires, voire élaborées, reportées dessus, et de lui laisser la partie vraiment “créative” avec des outils les plus simples possibles. Le tout avec une optimisation à la volée de l’utilisation du service en fonction de sa charge.

Je sais pas ce qu’en disent ceux qui utilisent le FaaS (c’est pas mon cas), mais je crois pas qu’il faille chercher du côté de la simplicité pour les arguments. Ça, c’est le discours marketing, mais il faut aussi voir qu’avec le FaaS on se créé une nouvelle dépendance vers un fournisseur externe qu’il faudra gérer différemment du reste de l’application qui elle n’est pas en FaaS. Donc, ça ajoute de la complexité. Si ce qu’on recherche c’est simplement un environnement prêt à l’emploi, le “platform as a service” le fournit aussi.

Je crois que le principal intérêt du FaaS est pour les boîtes qui veulent optimiser leur facturation aux petits oignons.

Cf aussi le commentaire de @MrKuja plus haut

Le 10/08/2020 à 09h 39

Et petite précision concernant le temps de démarrage : le passage de 0 workload à 1 (= cold start) est coûteux en effet, et le startup time a son impact. Mais passé ce cap, le scaling de 1 à N est beaucoup moins problématique puisque le load-balancer ne redirigera pas les requêtes vers un workload qui n’est pas encore prêt à les recevoir. Donc, pour un workload qui sera continuellement sollicité, donc jamais dormant, pas de cold start, donc le temps de démarrage n’est pas (trop) un problème.

Le 10/08/2020 à 09h 09

(quote:48611:chasis.fan)
Oui c’est pour ca que Java se tourne vers la compilation native avec GraalVM et des frameworks l’exploitant comme Quarkus ou Micronauts car plus trop adaptée pour des archi microservices devant être up scalé / down scalé le plus vite possible avec le moins de conso mémoire possible (plein d’instances qui bouffent plusieurs centaines de Mo de base ca coute sur les infra clouds ^^). Histoire de pas se laisser distance par Node.js / Go sur ces infra modernes.Vidéo intéressant sur le sujet : https://www.youtube.com/watch?v=bWW6oOC0400

Je tiens à ajouter que même hors compilation native, les JVM ne sont pas tant à la ramasse qu’on pourrait le croire, en startup time et empreinte mémoire. En général ce n’est pas tant la JVM le problème, que les surcouches qu’on y met: JEE / SpringBoot avec injections de dépendances etc. Si on prend un framework léger, de type Vert.x, il fait plus que tenir la comparaison avec Node.js en startup time (l’appli node.js n’étant pas non plus compilée faut-il préciser). Alors, c’est vrai que la JVM ça reste tout un tas de classes à charger, et c’est vrai que GraalVM permet à Java de revenir dans la course face aux langages compilés ; mais d’un autre côté, ce qu’on gagne en startup / mémoire, on en perd en optimisations JIT qui permettent parfois de meilleures perfs à chaud.

Bref tout ça pour dire que c’est compliqué :-)

Le 08/08/2020 à 11h 32

Même si je suis globalement d’accord, NodeJS a tout de même un certain mérite à mon avis, c’est d’avoir été l’un des premiers (le premier?) à populariser les non-blocking i/o et la programmation asynchrone, basée sur une event loop. Peut-être à la base surtout pour palier à l’absence de multi-threading, mais ça s’est avéré un choix payant et on a vu ce choix repris par la suite dans d’autres langages, notamment via Vert.x en Java par exemple.

Le 07/08/2020 à 17h 54

> “S’il y a d’autres paquets Node.JS ou pour d’autres langages/runtimes qui vous aident régulièrement, n’hésitez pas à nous le faire savoir dans les commentaires.”

Puisque vous demandez… TypeScript est franchement génial et permet de gommer beaucoup de défauts de javascript. IMHO l’un des languages les mieux conçus.

Le 20/07/2020 à 15h 11

Je sais pas si c’est dans la roadmap, mais ce serait top si Mozilla intègrait les réglages & comptes thunderbird dans firefox sync !

Le 20/07/2020 à 14h 25

Oui, à mon boulot c’est un peu comme ça :https://xkcd.com/1782/ " />

Mais slack gagne du terrain …

Le 02/07/2020 à 20h 56

loser a écrit :

Attention avec le plantage d’arbres, ça a l’air bien comme ça mais…



(Excellent article, merci pour cette lecture)

Le 26/06/2020 à 14h 49

Vivement qu’on ait des contraintes, les développeurs, concernant l’obsolescence logicielle. C’est trop souvent négligé. Même s’il n’y a aucune volonté de pousser au renouvellement de matériel, comme voudraient le croire les complotistes, il y a quand même énormément de négligence, par facilité. Parce que tant que les clients ne râlent pas, on s’en tape. Je vois des softs professionnels qui demandent +1GB de ram à chaque nouvelle version, c’est juste dément.

Après, quelle forme pourrait avoir des contraintes réglementaires ? Je serais curieux de savoir. Obliger à mentionner visiblement les coûts en ressources?

Le 22/06/2020 à 12h 18

Merci NI pour ce dossier Gaia-X en tout cas, c’est appréciable d’y voir un petit peu plus clair dans tout ce flou!

Le 22/06/2020 à 08h 07

TheKillerOfComputer a écrit :

Et c’est là que ça gène. S’adapter est une chose, mais ça a tendance à aller un peu trop vite à mon goût… et surtout le “Cloud” rend la chose compliquée car l’avantage du local est de permettre cela sur son temps libre avec un contrôle quasi total sur les coûts/l’équipement et la façon de simuler les problèmes… alors que le “Cloud” les retire tout ou partie. Azure par exemple offre bien 30 jours d’essai du premium mais ça me semble bien insuffisant pour tout essaier. A moins de créer 36 comptes avec fausses identités (ce n’est pas comme si je n’avais jamais fait cela dans ma vie " />).

  J'ai l'impression de vivre une période de transition local/cloud qui est extrémement pénible à vivre.

Ahh, mais les vendeurs de nuages ont une solution toute trouvée pour toi, ça s’appelle le cloud hybride!! " />
 

Le 19/06/2020 à 15h 07

Ben enfin, le serverless, le-cloud-sans-serveur-mais-en-fait-quand-meme-un-peu.

Le 19/06/2020 à 15h 03

Ça m’a l’air bien compliqué tout ça. S’ils arrivent à faire vivre le bousin, chapeau.
Je vois l’intérêt mais je vois aussi la complexité, et ce genre de chose peut jouer en défaveur de l’innovation. Sauront-ils tenir le rythme d’un google / amazon en terme de fonctionnalités?

Le 03/06/2020 à 15h 50

Tu devrais te mettre au Go alors si ce n’est pas déjà le cas, tu pourras t’y faire plein de copains! C’est plein de vieux bougons qui veulent pas de fonctionnel " />

(moi j’y suis mais contre mon gré)

Le 23/05/2020 à 07h 44

Tout à fait, en fait ils sont encore assez frileux malgré tout. C’est le full-remote qui serait un vrai changement de mentalité. Comme certaines boîtes de la tech ont annoncé récemment (twitter et facebook pour ne citer qu’eux)

Le 19/05/2020 à 10h 21

La plupart de ces points (le “?”, pattern matching, “Some”) se retrouvent aussi dans les évolutions récentes d’autres languages, dans des variantes plus ou moins élaborées et efficaces (typescript, kotlin … même un peu java à son rythme), il y a une sorte de convergence générale vers plus de programmation fonctionnelle dans la dernière décennie. Sauf Go bien sûr qui repart de la préhistoire " />.

Le 18/05/2020 à 19h 42

Uther a écrit :

D’autant plus que les points qui font la réputation de Rust comme la sécurité et la qualité du code, les gens qui font des jeux vidéo en ont encore plus rien a foutre que le reste de l’industrie de l’informatique, à tort à mon avis, mais c’est clairement le cas.

 

Ça reste à voir : le coût de développement serait plus élevé au démarrage (prototypage moins rapide, tout ça…) mais coût de débogage réduit.. à mon avis plus le projet est gros, plus rust devient avantageux.

Le 13/05/2020 à 17h 01

Autant je suis complètement pro-open source en général, autant là, c’est se tirer une balle dans le pied. Les pauvres devs vont en chier à gérer les shitstorms sur Twitter, les moqueries pas forcément justifiées etc. Bref pas le genre d’ambiance sereine qui sied à un travail de qualité

Le 07/05/2020 à 12h 42

Donc, une techno sans biais, sans parti pris à base de deep learning… Sur rien de plus que l’apparence physique… Non mais sérieux, c’est exactement la définition du biais et du parti pris.

Le 24/04/2020 à 20h 31

Regarde peut-être par là:https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables

Le 24/04/2020 à 20h 05

J’ai utilisé le spin XFCE pendant un bout de temps. C’était plutôt correct sans être parfait. Il y a sans doute beaucoup moins de développeurs que sur KDE. Par exemple, suite à une release les icônes du “xfce panel” (en gros les icônes de contrôle genre son, bluetooth wifi etc.) s’étaient mises à déconner, pour certaines ça a été vite corrigé pour d’autre les bugs ont duré plusieurs cycles de releases.
 
J’ai fini par rentrer dans le rang et passer sous gnome, notamment pour bénéficier de la “force de frappe” des développeurs gnome/redhat ; pas facile au début quand on est habitué au classicisme d’un xfce, mais on s’y fait très bien à la longue, je ne reviendrai pas en arrière :-)

Le 10/03/2020 à 10h 13

Allons voir ça sur le site de l’AN … oh bah mince, il faut se connecter avec google ou facebook? Je croyais qu’on avait un machin France Connect là… c’est ballot pour une consultation sur l’identité numérique 😅

Le 29/02/2020 à 11h 33

À propos de l’impact écologique du numérique, un blog post intéressant (et long) à lire :https://blog.jessfraz.com/post/power-to-the-people/

Le 24/02/2020 à 17h 40

Et sinon, un dossier Qwant?
(non j’déconne)

Le 24/02/2020 à 17h 31

Un sujet que j’aimerais bien voir abordé sérieusement, c’est l’empreinte écologique du numérique. Parce qu’on entend plein de choses à ce sujet dans la presse généraliste, avec souvent bien peu de recul ou de rigueur scientifique. Et souvent les deux mêmes sources mises en avant (ADEME et TheShiftProject) sans trop savoir que penser de leur fiabilité (personnellement ou tout cas). Je me rappelle d’un numéro récent de Linux Pratique (ou qqch dans le genre, pas sûr duquel) qui abordait le sujet mais de manière assez superficielle j’ai trouvé, sans que ça ne m’éclaire bien plus.

Bref perso c’est un sujet que j’aimerais beaucoup voir abordé avec sérieux et rigueur. À condition qu’il y ait des choses à en tirer bien sûr.

Le 24/02/2020 à 15h 33

Oh oui, avec une disquette contenant le code source, super idée " />

Le 28/02/2020 à 08h 00

Et peut-être que dans un an tu trouveras que JMM nous a bien pris pour des idiots avec un article plutôt à décharge?

JMM accuse des journaux de cherry-picking, d’absence de mise en contexte. Et ces journaux se défendent… en accusant JMM grosso-modo de la même chose, sélectivité etc. :https://blogs.mediapart.fr/la-redaction-de-mediapart/blog/270220/propos-de-notre…

Pour moi, les uns comme les autres partent de l’idée qu’ils ont quelque chose à prouver, et mettent tout en œuvre pour y arriver. Ce qui mène à des biais relativement classiques. Peut-être que parfois la presse ferait bien de s’inspirer de la méthode scientifique… mais bon sachant que même en science ce n’est pas toujours acquis, alors dans les média ….

Le 27/02/2020 à 14h 33

Illustration:https://xkcd.com/386/
" />

Le 26/02/2020 à 08h 24

Il n’y a rien à redire sur 90% des 4 articles. Il y a 10% problématiques, où on voit clairement un parti-pris pour Doucet contre Porcel en minimisant ce qu’il a fait. Si vous ne le voyez pas, re-visionnez peut-être l’émission d’arrêt sur image, relisez à tête reposée (je suis sûr que vous l’avez déjà relu 15 fois avant de publier, mais quand même) … prenez un bon bol d’air, essayez de vous mettre à la place de la victime en relisant. Je sais pas quoi dire, de mon point de vue ça parait tellement évident. Ça ne remet pas en cause les 90% restants des articles.

Le 26/02/2020 à 08h 00

“On juge du traitement médiatique de cette affaire précise”

D’accord, mais en préalable à ce jugement vous faites quand même assez clairement passer le message que Doucet était plus victime que bourreau en récusant le terme de harcèlement (si je suis bien sa “défense”, il ne serait pas harceleur du fait qu’il n’a fait qu’un seul canular à son encontre? Alors qu’il faut remettre ce canular dans le contexte du harcèlement dont elle était déjà victime - canular vécu selon ses dires même comme le point d’orgue du harcèlement).

 Donc, est-ce que c’est simplement une maladresse de votre part? Je n’en sais rien. Toujours est-il que vous prenez le risque de raviver des douleurs chez la victime, ne pensez-vous pas?

Le 25/02/2020 à 17h 58

J’ai revu l’émission d’arrêt sur image ou @manhack et Florence Porcel sont invités : https://www.arretsurimages.net/emissions/arret-sur-images/on-ne-peut-pas-reduire…  . Et j’ai quand même beaucoup de mal avec cet article.

Mankack: “L’absence de toute précaution de langage rendait in fine Doucet
co-responsable de ces actes, contribuant à le clouer au pilori, quand
bien même il n’a jamais été démontré, ni à l’époque ni depuis, qu’il ait
participé à une quelconque forme de harcèlement.”

Donc il faudrait dédouaner Doucet de ce harcèlement? Alors qu’il savait Florence Porcel ciblée par la ligue, et fait son canular (stocké sur un soundcloud dont le nom est l’anagramme de ligue du lol, s’il faut encore appuyer sur la relation) ? Mais non, pour lui ce serait différent et ça ne participerait pas au harcèlement? Pourquoi défendre ce point de vue, qu’est-ce que je n’ai pas compris?

Le 24/02/2020 à 11h 52

Intéressant (et merci pour le lien, je ne connaissais pas). Après une lecture rapide j’ai l’impression que le périmètre de ce DTP est assez restreint, ça semble concerner l’accès à l’ensemble des données statiques telle que prévue par le RGPD, donc un tout petit morceau de ce que couvrent les API de ces services. Par exemple ce serait insuffisant pour créer un nouveau client Twitter. Mais enfin oui, l’idée serait d’avoir ça, en beaucoup plus élargi.

Le 24/02/2020 à 10h 10

J’ai du mal aussi à imaginer obliger les gafam à l’interopérabilité.

En revanche, un changement de mentalité est certainement possible de leur propre part. De la même façon que l’open-source est devenue courante chez Google, Microsoft, Facebook et désormais de plus en plus Amazon ; peut-être qu’ils finiront également par voir qu’ouvrir les tuyaux (même sur des produits closed-source) peut leur être bénéfique pour créer un écosystème plus riche et autonome.

Le 21/01/2020 à 10h 44

L’élitisme à la Française. Même lorsqu’on veut copier les américains on retombe dans nos travers.