Le problème vient d’une mauvaise configuration du volume au démarrage du conteneur, pas du fait que les écritures concurrentes ne soient pas prises en charge. Si vous relisez l’article, il est indiqué que l’absence d’écritures concurrentes est largement compensée par le busy timeout. La configuration du volume peut être résolue avec ipc=host.
Postgres doit au final être exploité en production, alors qu’avec sqlite, il suffit de déployer le binaire de l’application n’importe où.
À force d’accumuler d’innombrables expériences d’exploitation et échecs, sqlite commence à gagner en popularité, et l’article indique clairement que les écritures concurrentes ne posent absolument pas problème.
Merci.
Les méthodes, tant pour la planification que pour le design, n’ont cessé d’évoluer, mais j’ai l’impression que le rythme s’accélère progressivement.
Après avoir lu l’article de blog en entier, j’ai l’impression que c’est au fond le travail que faisaient déjà les PM à l’origine. Simplement, avec l’arrivée de l’ère de l’IA, la manière de faire semble évoluer peu à peu. Merci pour ces excellents éclairages.
Tout le monde a déjà tenté une migration vers Linux une ou deux fois, et s’il y a eu des échecs, ce n’est pas sans raison, donc difficile de savoir comment cela se passera.
En Corée aussi, si le gouvernement a autrefois poussé des solutions basées sur Linux, c’était pour cette raison.
Comme le gouvernement peut malgré tout exercer un certain contrôle sur les entreprises coréennes.
Cela dit, la tendance semble aller davantage vers le web ou le SaaS que vers du Linux natif, et dans ce cas, on pourrait finir par créer une nouvelle forme de dépendance dans un autre domaine.
Même s’il y a des problèmes de complexité d’infrastructure, dans un contexte comme un site e-commerce où il faut beaucoup d’écritures concurrentes, n’est-ce pas un meilleur choix de ne pas utiliser sqlite dès le départ ?
Et si c’était en plus déployé avec Docker, la complexité d’infrastructure d’une configuration postgresql ne serait pas non plus si élevée.
J’ai l’impression que, puisque c’est fait avec rails et que l’écosystème est orienté vers l’utilisation de sqlite, on a été incité à penser que c’était une bonne idée.
Une erreur grave comme la perte de commandes s’est même produite, et dans un contexte comme un site e-commerce où il faut beaucoup d’écritures concurrentes, n’est-ce pas un meilleur choix de ne pas utiliser sqlite dès le départ, même s’il y a des problèmes d’écritures concurrentes avec pg ?
Comme c’est fait avec rails et que l’écosystème est structuré autour de l’usage de sqlite, j’ai aussi l’impression qu’on a été amené à penser que c’était une bonne solution.
Une erreur majeure comme la perte de commandes s’est produite, et la manière fondamentale de résoudre cela est d’utiliser une base de données gérant les écritures concurrentes comme pg.
Comme il y a une préférence technique pour sqlite, s’obstiner à dire qu’on va continuer à l’utiliser me paraît, en tant qu’ingénieur, être une déclaration qui entame ma confiance.
J’ai l’impression que c’est la version inverse du développement « résumé-driven », où l’on déploie k8s sans besoin réel, configure un HPA avec un seul replica, et transforme un monolithe qui fonctionnait bien en MSA.
Ce n’est pas vraiment une idée nouvelle à ce stade, mais cela me semble être une bonne approche dans la mesure où elle peut être mise en œuvre sans casser les signatures d’interface ni le workflow.
Plus précisément, on dirait que ce commentaire a été posté parce que les raisons pour lesquelles OpenAI, à l’époque où Amodei y était, a gardé GPT-2 privé ressemblent à celles invoquées pour ne pas rendre public le modèle Mischief. L’Amodei de l’époque et l’Amodei d’aujourd’hui n’ont pas changé...
Le problème vient d’une mauvaise configuration du volume au démarrage du conteneur, pas du fait que les écritures concurrentes ne soient pas prises en charge. Si vous relisez l’article, il est indiqué que l’absence d’écritures concurrentes est largement compensée par le
busy timeout. La configuration du volume peut être résolue avecipc=host.Postgres doit au final être exploité en production, alors qu’avec sqlite, il suffit de déployer le binaire de l’application n’importe où.
À force d’accumuler d’innombrables expériences d’exploitation et échecs, sqlite commence à gagner en popularité, et l’article indique clairement que les écritures concurrentes ne posent absolument pas problème.
J’espère qu’ils n’échoueront pas comme la ville de Munich. https://zdnet.co.kr/view/?no=20170213100421
Merci.
Les méthodes, tant pour la planification que pour le design, n’ont cessé d’évoluer, mais j’ai l’impression que le rythme s’accélère progressivement.
Après avoir lu l’article de blog en entier, j’ai l’impression que c’est au fond le travail que faisaient déjà les PM à l’origine. Simplement, avec l’arrivée de l’ère de l’IA, la manière de faire semble évoluer peu à peu. Merci pour ces excellents éclairages.
Tout le monde a déjà tenté une migration vers Linux une ou deux fois, et s’il y a eu des échecs, ce n’est pas sans raison, donc difficile de savoir comment cela se passera.
En Corée aussi, si le gouvernement a autrefois poussé des solutions basées sur Linux, c’était pour cette raison.
Comme le gouvernement peut malgré tout exercer un certain contrôle sur les entreprises coréennes.
Cela dit, la tendance semble aller davantage vers le web ou le SaaS que vers du Linux natif, et dans ce cas, on pourrait finir par créer une nouvelle forme de dépendance dans un autre domaine.
Les Skills, c’est l’escrime, et le mcp, c’est l’épée… L’usage est différent, et on a besoin des deux.
Oui, justement, c’est d’autant plus agréable de voir ce genre de billet apparaître de temps en temps.
Même s’il y a des problèmes de complexité d’infrastructure, dans un contexte comme un site e-commerce où il faut beaucoup d’écritures concurrentes, n’est-ce pas un meilleur choix de ne pas utiliser sqlite dès le départ ?
Et si c’était en plus déployé avec Docker, la complexité d’infrastructure d’une configuration postgresql ne serait pas non plus si élevée.
J’ai l’impression que, puisque c’est fait avec rails et que l’écosystème est orienté vers l’utilisation de sqlite, on a été incité à penser que c’était une bonne idée.
Une erreur grave comme la perte de commandes s’est même produite, et dans un contexte comme un site e-commerce où il faut beaucoup d’écritures concurrentes, n’est-ce pas un meilleur choix de ne pas utiliser sqlite dès le départ, même s’il y a des problèmes d’écritures concurrentes avec pg ?
Comme c’est fait avec rails et que l’écosystème est structuré autour de l’usage de sqlite, j’ai aussi l’impression qu’on a été amené à penser que c’était une bonne solution.
Une erreur majeure comme la perte de commandes s’est produite, et la manière fondamentale de résoudre cela est d’utiliser une base de données gérant les écritures concurrentes comme pg.
Comme il y a une préférence technique pour sqlite, s’obstiner à dire qu’on va continuer à l’utiliser me paraît, en tant qu’ingénieur, être une déclaration qui entame ma confiance.
J’ai l’impression que c’est la version inverse du développement « résumé-driven », où l’on déploie k8s sans besoin réel, configure un HPA avec un seul replica, et transforme un monolithe qui fonctionnait bien en MSA.
Si l’État l’adopte, qu’il consacre aussi cet argent au soutien du développement de Linux...
De toute façon, l’industrie de l’IA est déjà en pleine tempête, infestée de pseudo-prédicateurs.
Les Skills et le MCP ont des rôles différents, mais j’ai l’impression que ce genre d’articles continue d’entretenir la confusion.
C’est parce qu’il faut faire la promo de MCP Nest à la fin de l’article… haha. On dirait que pas mal d’arguments comparatifs gagnent en popularité.
Ce sont simplement deux choses complètement différentes, alors pourquoi ce genre de discussions continue-t-il à revenir ?
À voir avec les articles recommandés, on dirait que toute l’Europe évolue dans cette direction.
Ils devraient d’abord stabiliser un peu la fonctionnalité des canaux...
Je pense que les personnes qui connaissent les goulots d’étranglement sur le terrain sont essentielles.
En y repensant maintenant, c’est assez drôle lol. Le fait qu’en moins de 10 ans la situation soit devenue presque risible fait aussi un peu peur.
Ce n’est pas vraiment une idée nouvelle à ce stade, mais cela me semble être une bonne approche dans la mesure où elle peut être mise en œuvre sans casser les signatures d’interface ni le workflow.
Plus précisément, on dirait que ce commentaire a été posté parce que les raisons pour lesquelles OpenAI, à l’époque où Amodei y était, a gardé GPT-2 privé ressemblent à celles invoquées pour ne pas rendre public le modèle Mischief. L’Amodei de l’époque et l’Amodei d’aujourd’hui n’ont pas changé...
La plupart sont censés être récupérés, mais celui-ci a été traité en étant étrangement omis. Je vais le corriger pour qu’on n’y touche pas.