Dans Edge, Microsoft tente déjà une intégration avec son propre LLM, donc ce n’est pas vraiment une nouveauté. Mais est-il vraiment nécessaire d’aller jusqu’à une acquisition ? Cela ressemble davantage à une tentative d’étendre le service à tous les utilisateurs de Chrome qu’à un effort de développement. Penser pour autant qu’OpenAI peut ouvrir la voie à un navigateur centré sur l’IA me paraît excessif. À ce compte-là, Google Gemini pourrait tout autant le faire.
L’objectif n’est sans doute pas de calculer avec précision le temps estimé nécessaire pour la visite, mais plutôt de montrer l’intérêt d’avoir résolu le TSP à partir de données du monde réel.
Pendant un temps, le tweet et la vidéo[1] expliquant qu’ils avaient abandonné l’Edge rendering de Vercel, ainsi que l’article sur les serverless servers (mdr)[2], ont beaucoup fait parler d’eux. J’ai l’impression d’avoir un point de vue assez proche de celui des textes parus à ce moment-là.
C’est un avis personnel, mais du point de vue d’un développeur frontend, je pense qu’attacher des serverless functions aux requêtes des utilisateurs est encore une perspective lointaine (sauf si l’application qu’on veut créer est un MVP).
Je ne nierai pas que tout le monde peut tenter sa chance. Mais dire que n’importe qui peut facilement devenir un pro, c’est faux. J’espère que vous ne vous promenez pas à dire ça aux gens dans la vraie vie. Parce que c’est une arnaque.
Dans les sciences et l’ingénierie, dans quel domaine peut-on devenir un expert apte à être envoyé en production en seulement quelques mois en restant chez soi, à regarder un peu Internet et à apprendre en autodidacte (si tout se passe bien) ? <- Quel que soit le domaine, personne ne qualifie d’expert un candidat débutant de ce genre. Quelqu’un l’a déjà critiqué avant moi. Si vous pensez vraiment ainsi, c’est que votre niveau de réflexion est faible et que vous manquez aussi de conscience professionnelle.
On a l’impression que vous pensez à tort que le développement logiciel consiste simplement à générer du code ou à créer des API. L’essence du développement logiciel, c’est d’abstraire la réalité pour créer des protocoles et des interfaces, puis d’y faire entrer les différents éléments. Autrement dit, il s’agit de relier des choses qui fonctionnent de manière différente pour qu’elles agissent comme un tout. C’est une activité intellectuelle bien plus complexe qu’on ne le pense, et c’est pour cela qu’il est plus difficile qu’on l’imagine de former de bons ingénieurs logiciel. On dit qu’il y a beaucoup de monde aujourd’hui, mais parmi eux, combien sont réellement capables de bien faire le travail ? La plupart ont simplement essayé un outil ou deux, mais ce n’est pas là le cœur du métier d’ingénieur logiciel.
J’étais déçu que Samsung ait arrêté la prise en charge de Linux on DeX,
mais cette fois, Google tente l’expérience directement de son côté.
C’est une bonne nouvelle.
Puisqu’il y a des personnes qui parlent d’expérience de développement et d’observabilité, j’ajouterais ceci :
si l’on met bien en place l’environnement d’intégration initial, on peut obtenir une expérience de développement qui n’a rien à envier à une approche basée sur les conteneurs, voire qui est encore plus proche du natif. (Il existe d’ailleurs divers outils pour cela.)
Quant à l’observabilité, si l’on veut aller en profondeur, ni le serverless ni l’approche basée sur les conteneurs n’en font un sujet particulièrement simple. Centralisation des logs, visualisation de diverses métriques, APM, visualisation de l’utilisation CPU/mémoire et définition de stratégies de scaling en conséquence, etc.
Si l’on n’en est pas à ce niveau-là, l’intégration métriques/logs fournie par défaut par le cloud vendor est suffisamment puissante, donc au final c’est kif-kif.
Pour le dire de manière agressive, j’aurais envie de demander : « Jusqu’à quel point avez-vous vraiment fait du serverless correctement ? » 😅
Ayant travaillé à la fois dans des environnements basés sur des conteneurs (principalement ECS Fargate et des clusters Kubernetes) et dans des environnements serverless (AWS), ça ne me parle pas vraiment tant que ça.
Les points présentés comme des avantages d’un environnement basé sur des conteneurs sont aussi, en même temps, des aspects qui peuvent devenir des inconvénients.
Tout ce qui est mentionné sous l’angle du « contrôle direct » et du fait de « pouvoir conserver un état » devient aussi, d’une certaine manière, autant de points de gestion supplémentaires qui rendent l’exploitation plus difficile.
Pour ma part, je recommande vivement le serverless, surtout aux petites organisations ou à celles qui n’ont pas d’équipe spécialisée dans l’administration serveur.
Ah, en revanche, je suis d’accord sur le fait que le calcul des coûts soit complexe ou difficile à prévoir, ainsi que sur le problème de vendor lock-in.
Comme d’autres commentaires le disent, les personnes qui travaillent chez Samsung, Naver, etc., puis partent chez AMD, Google, etc., finiraient par représenter un atout majeur si elles revenaient en Corée avec leur expérience. Mais dans une telle ambiance, non seulement elles ne reviendront pas, elles continueront même à partir. Ce n’est pas simplement une question d’argent, c’est aussi que l’environnement et la perception sont déplorables.
Au fond, qu’est-ce que vous voulez dire ? La Corée n’est pas un pays où les ingénieurs sont particulièrement bien traités. Si vous avez l’impression d’être payé davantage que ce que vaut votre travail, vous pouvez toujours faire un don quelque part. Est-ce que le problème, en Corée, c’est vraiment un environnement où les ingénieurs seraient arrogants ? Le vrai problème, c’est plutôt que les conditions y sont moins bonnes qu’à l’étranger, si bien que les plus compétents changent d’emploi et ne reviennent pas (même s’il peut bien sûr y avoir aussi des gens arrogants).
Dans Edge, Microsoft tente déjà une intégration avec son propre LLM, donc ce n’est pas vraiment une nouveauté. Mais est-il vraiment nécessaire d’aller jusqu’à une acquisition ? Cela ressemble davantage à une tentative d’étendre le service à tous les utilisateurs de Chrome qu’à un effort de développement. Penser pour autant qu’OpenAI peut ouvrir la voie à un navigateur centré sur l’IA me paraît excessif. À ce compte-là, Google Gemini pourrait tout autant le faire.
Waouh, c’est vraiment excellent. À deux, cela n’a pas dû être simple pour vous d’obtenir jusqu’aux données d’entraînement, c’est impressionnant.
Le créateur est même venu en personne~ Il faudra que j’essaie ça moi aussi.
MDRRRR
La page en anglais est https://www.math.uwaterloo.ca/tsp/korea/index.html.
Le parcours est clairement irréaliste. Il semble qu’il ne prenne pas en compte les liaisons maritimes en ferry pour aller du continent à Jeju ou à Ulleungdo. Il suffit de regarder cette image : https://www.math.uwaterloo.ca/tsp/korea/img/full_line.png
L’objectif n’est sans doute pas de calculer avec précision le temps estimé nécessaire pour la visite, mais plutôt de montrer l’intérêt d’avoir résolu le TSP à partir de données du monde réel.
Bien sûr, comme cela a aussi été noté sur ce post, on dirait que c’est un article volontairement très racoleur :(
Pendant un temps, le tweet et la vidéo[1] expliquant qu’ils avaient abandonné l’Edge rendering de Vercel, ainsi que l’article sur les serverless servers (mdr)[2], ont beaucoup fait parler d’eux. J’ai l’impression d’avoir un point de vue assez proche de celui des textes parus à ce moment-là.
C’est un avis personnel, mais du point de vue d’un développeur frontend, je pense qu’attacher des serverless functions aux requêtes des utilisateurs est encore une perspective lointaine (sauf si l’application qu’on veut créer est un MVP).
[1] https://youtu.be/lAGE-k1Zfrg
[2] https://vercel.com/blog/…
[2-1] https://bobaekang.com/blog/…
Je ne comprends pas encore très bien les conteneurs bootables.
Je ne nierai pas que tout le monde peut tenter sa chance. Mais dire que n’importe qui peut facilement devenir un pro, c’est faux. J’espère que vous ne vous promenez pas à dire ça aux gens dans la vraie vie. Parce que c’est une arnaque.
Dans les sciences et l’ingénierie, dans quel domaine peut-on devenir un expert apte à être envoyé en production en seulement quelques mois en restant chez soi, à regarder un peu Internet et à apprendre en autodidacte (si tout se passe bien) ? <- Quel que soit le domaine, personne ne qualifie d’expert un candidat débutant de ce genre. Quelqu’un l’a déjà critiqué avant moi. Si vous pensez vraiment ainsi, c’est que votre niveau de réflexion est faible et que vous manquez aussi de conscience professionnelle.
C’est facile, de passer d’amateur à professionnel ? Si c’était vrai, on n’appellerait plus ça être un pro.
On a l’impression que vous pensez à tort que le développement logiciel consiste simplement à générer du code ou à créer des API. L’essence du développement logiciel, c’est d’abstraire la réalité pour créer des protocoles et des interfaces, puis d’y faire entrer les différents éléments. Autrement dit, il s’agit de relier des choses qui fonctionnent de manière différente pour qu’elles agissent comme un tout. C’est une activité intellectuelle bien plus complexe qu’on ne le pense, et c’est pour cela qu’il est plus difficile qu’on l’imagine de former de bons ingénieurs logiciel. On dit qu’il y a beaucoup de monde aujourd’hui, mais parmi eux, combien sont réellement capables de bien faire le travail ? La plupart ont simplement essayé un outil ou deux, mais ce n’est pas là le cœur du métier d’ingénieur logiciel.
J’étais déçu que Samsung ait arrêté la prise en charge de Linux on DeX,
mais cette fois, Google tente l’expérience directement de son côté.
C’est une bonne nouvelle.
Puisqu’il y a des personnes qui parlent d’expérience de développement et d’observabilité, j’ajouterais ceci :
si l’on met bien en place l’environnement d’intégration initial, on peut obtenir une expérience de développement qui n’a rien à envier à une approche basée sur les conteneurs, voire qui est encore plus proche du natif. (Il existe d’ailleurs divers outils pour cela.)
Quant à l’observabilité, si l’on veut aller en profondeur, ni le serverless ni l’approche basée sur les conteneurs n’en font un sujet particulièrement simple. Centralisation des logs, visualisation de diverses métriques, APM, visualisation de l’utilisation CPU/mémoire et définition de stratégies de scaling en conséquence, etc.
Si l’on n’en est pas à ce niveau-là, l’intégration métriques/logs fournie par défaut par le cloud vendor est suffisamment puissante, donc au final c’est kif-kif.
Pour le dire de manière agressive, j’aurais envie de demander : « Jusqu’à quel point avez-vous vraiment fait du serverless correctement ? » 😅
Ayant travaillé à la fois dans des environnements basés sur des conteneurs (principalement ECS Fargate et des clusters Kubernetes) et dans des environnements serverless (AWS), ça ne me parle pas vraiment tant que ça.
Les points présentés comme des avantages d’un environnement basé sur des conteneurs sont aussi, en même temps, des aspects qui peuvent devenir des inconvénients.
Tout ce qui est mentionné sous l’angle du « contrôle direct » et du fait de « pouvoir conserver un état » devient aussi, d’une certaine manière, autant de points de gestion supplémentaires qui rendent l’exploitation plus difficile.
Pour ma part, je recommande vivement le serverless, surtout aux petites organisations ou à celles qui n’ont pas d’équipe spécialisée dans l’administration serveur.
Ah, en revanche, je suis d’accord sur le fait que le calcul des coûts soit complexe ou difficile à prévoir, ainsi que sur le problème de vendor lock-in.
Dès le départ, ce n’était pas du
serverless, mais duserverlease.Comme d’autres commentaires le disent, les personnes qui travaillent chez Samsung, Naver, etc., puis partent chez AMD, Google, etc., finiraient par représenter un atout majeur si elles revenaient en Corée avec leur expérience. Mais dans une telle ambiance, non seulement elles ne reviendront pas, elles continueront même à partir. Ce n’est pas simplement une question d’argent, c’est aussi que l’environnement et la perception sont déplorables.
Au fond, qu’est-ce que vous voulez dire ? La Corée n’est pas un pays où les ingénieurs sont particulièrement bien traités. Si vous avez l’impression d’être payé davantage que ce que vaut votre travail, vous pouvez toujours faire un don quelque part. Est-ce que le problème, en Corée, c’est vraiment un environnement où les ingénieurs seraient arrogants ? Le vrai problème, c’est plutôt que les conditions y sont moins bonnes qu’à l’étranger, si bien que les plus compétents changent d’emploi et ne reviennent pas (même s’il peut bien sûr y avoir aussi des gens arrogants).
Félicitations. Un autre framework js vient de naître.
Ah oui, ça semble être ça mdr hahaha