Les paliers sont un peu perturbants, si on passe de 35 à 36 mails, de 5Go à 6Go BOUM! Ca reviendrait moins cher de prendre deux comptes que de passer au plan suivant. Le Go est proportionnellement moins cher sur le plan évolution que sur le plan professionnel.
Est-ce qu'il est prévu d'avoir une tarification plus progressive ?
Les scientifiques ont observé que les pays qui disposent des parcs nucléaires les plus importants n’ont pas tendance à réduire significativement leurs émissions. Dans les pays peu développés, les programmes nucléaires semblent même être associés à un accroissement de celles-ci.
A l’inverse, les Etats qui s’engagent dans des politiques donnant la priorité aux renouvelables parviennent mieux à réduire leurs émissions, et cela quel que soit le niveau de leur PIB ou la période observée.
C'est justement du fait que le CO2 s'accumule qu'il faut diminuer le plus rapidement possible. Plus on attend plus l'effort devra être important et inversement plus on diminue rapidement plus ça nous laisse du temps.
C'est un peu pareil à part que c'est du catchall.
Dans le fond ça revient au même, qu'on "lance des exceptions" qu'on "rattrape" ou qu'on renvoi des "erreurs" qu'on traite comme des valeurs…
Je trouve que la confusion vient du terme "error" qu'on aurait plutôt du appeler "status" ou quelque chose comme ça. C'est une simple information, pas forcément une erreur.
Par exemple io.EOF, sql.ErrNoRows, j'ai des handlers peuvent renvoyer une "erreur" de type Redirect etc.
Du coup c'est une valeur retournée comme une autre et donc traitée comme n'importe quelle valeur.
Comme Go est au départ utilisé pour du réseau le fait que cette "erreur" doit pouvoir renvoyer un string permet de faire transiter tout ça facilement.
C'est aussi comme les retours de commandes unix qui renvoient 0 1 -1…
Y a un copain qui m'a dit récemment, mais tu gérais les erreurs aussi comme ça en Python !
Les véritables erreurs c'est plutôt les panics qu'on rattrape avec recover.
Ca vaut vraiment le coup de fouiller un peu pour trouver les articles et confs qu'ils ont faits sur le sujet, l'équipe est d'un niveau assez impressionnant et les explications très détaillées.
Comme je ne note jamais rien j'ai aucun lien à donner…
D'après cette excellente description il serait possible de générer du code Go à partir du V et inversement et plus facilement que du C, est-ce que ça a été tenté ?
Je me demande tout de même à quel point ça a dû être complexe d'implémenter les garanties ACID en stateless.
Dans l'idée ça reste très classique, il y à toujours qu'un seul master, il n'y a que la couche de stockage qui change avec un serveur "pageserver" (un seul aussi et qui ne bouge pas) qui fait cache et le stockage persistant en copy-and-write.
Je ne répondais pas à ton commentaire non plus, je complémentais !
Je ne retrouve pas la source mais un des fondateur de Neon avait expliqué que l'idée lui était venu par rapport à une procédure qu'il avait mis en place en local, je ne me souviens plus exactement, probablement à base de snapshots fichiers.
Ce qui est pratique avec le côté service c'est également quand la base est très grosse et qu'il est trop long de la rapatrier chaque fois en local pour du dev ou des tests.
Pour l'instant chez eux cette option de scaling coûte plutôt moins cher que sans. Si on considère que c'est de facto une forme de haute dispo c'est même carrément moins cher.
Le côté cloud/serverless n'est pas que, c'est pour ça que j'ai surtout voulu parler du principe des branches.
On a la branche principale qui est celle de prod et on peut créer une branche pour faire un test de dev. C'est du copy-on-write, les données présentes ne sont pas dupliquées, seules les nouvelles données seront séparées. La séparation stockage/moteur permet de lancer un postgresql sur ce stockage dev avec ou pas les mêmes caractéristiques de mémoire etc.
Autant la charge est souvent prédictive en général autant il y a toujours des périodes de grosses mises à jour où on a besoin de plus de puissance très ponctuellement, l'auto scaling est très intéressant dans ce cas.
Sur des applications qui sont utilisées aux horaires de bureau c'est rudement intéressant aussi.
Dans les databases des databases il y a Neon.
Pouvoir faire une branche d'une DB quelque soit sa taille aussi rapidement qu'on ferait un git branch, franchement, c'est une tuerie. En prime ça descend à l'échelle jusque dans la cave.
A l'époque on s'échangeait les disquettes, c'est de ce même réseau qu'on se connaissait. Y avait aussi quelques mentions dans les revues.
Alors je dois avoir du code dans des vieux cartons dans un vieux garage assez loin, aucune idée si c'est encore récupérable. Mais c'est de l'assembleur 6502 sans aucun commentaire, ça pique un peu aujourd'hui !
L'ordinateur était donc éteint, quand le téléphone sonnait driiin, pause, driiin ça envoyait du jus pendant le driiin, l'électro-aimant s'activait, l'ordinateur démarrait, dès la fin du driiin plus de jus, plus d'électro-aimant actif, il fallait donc que l'ordinateur démarre et tout de suite actionne à son tour l'électro aimant. Pour ça c'était codé en language machine et ça démarrait sans OS, on appelait ça un "fast-boot". Le programme était chargé directement au boot, sans OS pour enregistrer les données on les enregistrait sur la disquette directement secteur par secteur.
Un micro serveur c'était un petit micro, un Apple ][, un Atari ST etc. sur lequel on codait un serveur, à peu près de la même manière qu'un serveur web, quelque chose qui écoute et qui répond. Comme tout le monde avait un minitel on connectait le minitel à l'ordinateur et on utilisait le modem du minitel pour écouter. Le minitel était bien sûr relié à la ligne téléphonique. Les visiteurs appelaient notre numéro de téléphone, le téléphone sonnait, on décrochait et on "envoyait la porteuse", le visiteur entendait la porteuse (un son continu strident) et connectait son minitel (une touche "connection"). Une fois connecté il pouvait accéder au serveur, ensuite il raccrochait pour libérer la ligne et quelqu'un d'autre pouvait appeler. Le minitel n'est qu'un simple terminal, une sorte de navigateur.
Au début on entendait la sonnerie, on courrait, on décrochait et la personne disait qu'elle voudrait se connecter, on lançait la porteuse. Ensuite on se faisait un petit boitier électronique qui décrochait et envoyait la porteuse tout seul mais du coup si c'était quelqu'un qui voulait parler il se recevait une porteuse en pleine poire ! Donc y avait des horaires et les plus riches avaient une ligne dédiée.
Comme les ordinateurs chauffaient, (ils n'avaient pas de ventilateur) avec mon paternel on avait fait un boitier électronique avec un électro-aimant qui allumait l'ordinateur quand le téléphone sonnait et qui l'éteignait quand la personne partait, une sorte de cloudrun quoi !
Chaque micro serveur était codé à la main et avait souvent un thème, par exemple un thème sur le hacking, un thème sur la prog, jeux etc, quelques pages de texte et quelques pages de type forum. On pouvait également communiquer directement, uniquement entre celui qui avait le micro-serveur et l'appelant.
Les BBS c'est un peu différent. Ils utilisaient aussi les lignes téléphoniques et les modems mais ils communiquaient entre eux pour partager les messages, comme les newsgroups. Ceux qui communiquaient étaient appelés des "nœuds". Les utilisateurs se connectaient à un des noeuds, le plus proche souvent, à l'aide d'un autre micro qui devait avoir un client adapté (et donc pas un terminal comme le minitel). Et à intervalle régulier les noeuds s'appelaient les uns les autres pour partager les messages. C'était un système très résilient, comme les mails et les newsgroups.
Ca me rappelle l'époque des microserveurs minitel dans les années 80, on inversait le modem du minitel 1200/75 bauds, ils étaient branchés sur la ligne de téléphone familiale et on se donnait des heures d'ouvertures pour ne pas saturer la ligne et ne pas faire trop chauffer le micro. Chaque serveur indiquait ces heures d'ouvertures et ça semblait tout à fait normal vu que dans la vraie vie c'est bien comme ça que ça marche à part quelques exceptions comme les pompiers et les hôpitaux.
Une étude publiée cette semaine dans la revue Nature Energy par des scientifiques de l’Université du Sussex en Grande-Bretagne et de l’International School of Management révèle que les énergies renouvelables sont jusqu’à 7 fois plus efficaces que le nucléaire pour réduire les émissions de CO2.
Les chercheurs ont analysé des données récoltées par la Banque Mondiale et l’Agence Internationale de l’Energie (AIE) dans 123 pays pendant 25 ans
Les scientifiques ont observé que les pays qui disposent des parcs nucléaires les plus importants n’ont pas tendance à réduire significativement leurs émissions. Dans les pays peu développés, les programmes nucléaires semblent même être associés à un accroissement de celles-ci.
A l’inverse, les Etats qui s’engagent dans des politiques donnant la priorité aux renouvelables parviennent mieux à réduire leurs émissions, et cela quel que soit le niveau de leur PIB ou la période observée.
« L’analyse des données récoltées indique clairement que le nucléaire est la moins efficace des deux principales politiques de réduction des émissions de carbone » nous confie Benjmin Sovacool, professeur à l’Université du Sussex. « Comme la coexistence des deux stratégies dans un même Etat semble difficile, il ne paraît pas sage de développer les investissements dans l’atome car ils se feront au détriment des renouvelables » poursuit-il. Pour son collègue Andy Stirling, l’étude démontre l’incohérence des arguments qui plaident pour un développement simultané des deux sources d’énergie car « les tensions et les incompatibilités qui existent entre elles risquent de ruiner les efforts faits pour combattre les changements climatiques ».
Par contre je ne vais pas me mettre à considérer les libristes comme des opprimés qu'il faudrait protéger.
J'ai du rater un épisode dans les commentaires mais on ne manque pas d'exemples d’oppressions dues à la dépendance dans des technologies/logiciels fermées à diverses échelles, pays , collectivités, individus… L'idée reste la même en tout cas.
Le seul argument donné est que si on fait ça alors ça va être au détriment du renouvelable : le présent montre que ce n'est pas complètement vrai,
Ben si justement le présent montre que c'est le cas (d'où l'intérêt des études sur le sujet). Autant au niveau économique que politique.
A part en Chine peut-être car ils n'ont pas nos contraintes démocratiques et d'alliance avec les voisins.
Tu as raison de ne pas vouloir tout arrêter brusquement mais je crois que tout le monde est d'accord là dessus aujourd'hui même si le curseur est difficile à trouver.
A mon avis on ne va rien décider du tout, c'est un événement quelconque qui décidera, un coup c'était un accident majeur, maintenant c'est le gaz russe. Demain le résultat d'une élection ?
Je suis juste pas d'accord avec le fait qu'être contre quelque chose implique obligatoirement qu'on ait un biais. Ca peut être au contraire les compétences dans un domaine qui nous amènent à nous positionner et être considéré comme tel.
On (a) subit déjà énormément d'à priori dans notre domaine (le libre) il faut se méfier de ne pas faire la même chose.
J'ai l'impression que certains ici veulent à tout prix se convaincre que les auteurs sont anti-nucléaires
Ils sont anti-nucléaire, c'est clair
En quoi ce serait un problème ? On est bien anti logiciels privateurs ici, ça n'enlève rien à nos compétences en la matière, bien au contraire.
Quand tu fais du vélo tu connais bien mieux les risques qu'engendre une voiture qu'un automobiliste en général.
# Paliers
Posté par wilk . En réponse au journal [publicité] galae, le service email éthique et libre (et français) est désormais ouvert \o/. Évalué à 8.
Les paliers sont un peu perturbants, si on passe de 35 à 36 mails, de 5Go à 6Go BOUM! Ca reviendrait moins cher de prendre deux comptes que de passer au plan suivant. Le Go est proportionnellement moins cher sur le plan évolution que sur le plan professionnel.
Est-ce qu'il est prévu d'avoir une tarification plus progressive ?
[^] # Re: Prédictions
Posté par wilk . En réponse au lien Dérèglement climatique: des scientifiques dénoncent une menace existentielle pour la vie sur Terre. Évalué à 3.
La démocratie actuelle est déjà un système "où des -autoproclamés- experts déterminent la politique optimale".
[^] # Re: hx-on
Posté par wilk . En réponse au lien Surfacing request errors when using HTMX. Évalué à 2. Dernière modification le 18 octobre 2023 à 18:36.
Je viens de voir cette issue : https://github.com/bigskysoftware/htmx/issues/1529
On devrait pouvoir toutes les rattraper avec
hx-on::error# hx-on
Posté par wilk . En réponse au lien Surfacing request errors when using HTMX. Évalué à 4.
Il me semble que maintenant on peut faire plus simple :
<body hx-on::response-error="alert('oups')">[^] # Re: tldr
Posté par wilk . En réponse au lien Rapport du haut conseil pour le climat. Évalué à 6.
Inutile d'aller chercher si loin, "on adore la bagnole" tout simplement (et aussi un peu l'avion).
[^] # Re: Deja vu
Posté par wilk . En réponse au lien Plus de 1000 scientifiques lancent un appel contre la relance du nucléaire en France. Évalué à 3.
Dans l'idéal le nucléaire servirait de base aux ENR et de ce fait permettrait un développement encore plus massif et surtout rapide des ENR.
Mais de fait c'est l'inverse, c'est ce qui pose problème et impose du coup de le rejeter faute de consensus.
https://www.revolution-energetique.com/le-nucleaire-est-moins-efficace-que-les-renouvelables-pour-reduire-les-emissions-de-carbone/ (étude scientifique)
[^] # Re: Deja vu
Posté par wilk . En réponse au lien Plus de 1000 scientifiques lancent un appel contre la relance du nucléaire en France. Évalué à 6.
C'est justement du fait que le CO2 s'accumule qu'il faut diminuer le plus rapidement possible. Plus on attend plus l'effort devra être important et inversement plus on diminue rapidement plus ça nous laisse du temps.
[^] # Re: Deja vu
Posté par wilk . En réponse au lien Plus de 1000 scientifiques lancent un appel contre la relance du nucléaire en France. Évalué à 10.
Moi je pense qu'aujourd'hui l'urgence c'est de moins émettre de CO2 dans les 50 dernières années.
[^] # Re: Une gestion d’erreur moderne ?
Posté par wilk . En réponse à la dépêche À la découverte du langage V. Évalué à 3.
C'est un peu pareil à part que c'est du catchall.
Dans le fond ça revient au même, qu'on "lance des exceptions" qu'on "rattrape" ou qu'on renvoi des "erreurs" qu'on traite comme des valeurs…
[^] # Re: Une gestion d’erreur moderne ?
Posté par wilk . En réponse à la dépêche À la découverte du langage V. Évalué à 4.
Je trouve que la confusion vient du terme "error" qu'on aurait plutôt du appeler "status" ou quelque chose comme ça. C'est une simple information, pas forcément une erreur.
Par exemple io.EOF, sql.ErrNoRows, j'ai des handlers peuvent renvoyer une "erreur" de type Redirect etc.
Du coup c'est une valeur retournée comme une autre et donc traitée comme n'importe quelle valeur.
Comme Go est au départ utilisé pour du réseau le fait que cette "erreur" doit pouvoir renvoyer un string permet de faire transiter tout ça facilement.
C'est aussi comme les retours de commandes unix qui renvoient 0 1 -1…
Y a un copain qui m'a dit récemment, mais tu gérais les erreurs aussi comme ça en Python !
Les véritables erreurs c'est plutôt les panics qu'on rattrape avec recover.
[^] # Re: Neon c'est bon.
Posté par wilk . En réponse au lien database of Databases. Évalué à 2.
Ca vaut vraiment le coup de fouiller un peu pour trouver les articles et confs qu'ils ont faits sur le sujet, l'équipe est d'un niveau assez impressionnant et les explications très détaillées.
Comme je ne note jamais rien j'ai aucun lien à donner…
# Go <-> V
Posté par wilk . En réponse à la dépêche À la découverte du langage V. Évalué à 4.
D'après cette excellente description il serait possible de générer du code Go à partir du V et inversement et plus facilement que du C, est-ce que ça a été tenté ?
[^] # Re: Neon c'est bon.
Posté par wilk . En réponse au lien database of Databases. Évalué à 3.
Dans l'idée ça reste très classique, il y à toujours qu'un seul master, il n'y a que la couche de stockage qui change avec un serveur "pageserver" (un seul aussi et qui ne bouge pas) qui fait cache et le stockage persistant en copy-and-write.
[^] # Re: Neon c'est bon.
Posté par wilk . En réponse au lien database of Databases. Évalué à 3.
Je ne répondais pas à ton commentaire non plus, je complémentais !
Je ne retrouve pas la source mais un des fondateur de Neon avait expliqué que l'idée lui était venu par rapport à une procédure qu'il avait mis en place en local, je ne me souviens plus exactement, probablement à base de snapshots fichiers.
Ce qui est pratique avec le côté service c'est également quand la base est très grosse et qu'il est trop long de la rapatrier chaque fois en local pour du dev ou des tests.
Pour l'instant chez eux cette option de scaling coûte plutôt moins cher que sans. Si on considère que c'est de facto une forme de haute dispo c'est même carrément moins cher.
[^] # Re: Neon c'est bon.
Posté par wilk . En réponse au lien database of Databases. Évalué à 3.
Le côté cloud/serverless n'est pas que, c'est pour ça que j'ai surtout voulu parler du principe des branches.
On a la branche principale qui est celle de prod et on peut créer une branche pour faire un test de dev. C'est du copy-on-write, les données présentes ne sont pas dupliquées, seules les nouvelles données seront séparées. La séparation stockage/moteur permet de lancer un postgresql sur ce stockage dev avec ou pas les mêmes caractéristiques de mémoire etc.
Autant la charge est souvent prédictive en général autant il y a toujours des périodes de grosses mises à jour où on a besoin de plus de puissance très ponctuellement, l'auto scaling est très intéressant dans ce cas.
Sur des applications qui sont utilisées aux horaires de bureau c'est rudement intéressant aussi.
# Neon c'est bon.
Posté par wilk . En réponse au lien database of Databases. Évalué à 2.
Dans les databases des databases il y a Neon.
Pouvoir faire une branche d'une DB quelque soit sa taille aussi rapidement qu'on ferait un git branch, franchement, c'est une tuerie. En prime ça descend à l'échelle jusque dans la cave.
[^] # Re: Un autre site solaire
Posté par wilk . En réponse au lien Solar Protocol. Évalué à 5.
A l'époque on s'échangeait les disquettes, c'est de ce même réseau qu'on se connaissait. Y avait aussi quelques mentions dans les revues.
Alors je dois avoir du code dans des vieux cartons dans un vieux garage assez loin, aucune idée si c'est encore récupérable. Mais c'est de l'assembleur 6502 sans aucun commentaire, ça pique un peu aujourd'hui !
L'ordinateur était donc éteint, quand le téléphone sonnait driiin, pause, driiin ça envoyait du jus pendant le driiin, l'électro-aimant s'activait, l'ordinateur démarrait, dès la fin du driiin plus de jus, plus d'électro-aimant actif, il fallait donc que l'ordinateur démarre et tout de suite actionne à son tour l'électro aimant. Pour ça c'était codé en language machine et ça démarrait sans OS, on appelait ça un "fast-boot". Le programme était chargé directement au boot, sans OS pour enregistrer les données on les enregistrait sur la disquette directement secteur par secteur.
[^] # Re: Un autre site solaire
Posté par wilk . En réponse au lien Solar Protocol. Évalué à 6.
Un micro serveur c'était un petit micro, un Apple ][, un Atari ST etc. sur lequel on codait un serveur, à peu près de la même manière qu'un serveur web, quelque chose qui écoute et qui répond. Comme tout le monde avait un minitel on connectait le minitel à l'ordinateur et on utilisait le modem du minitel pour écouter. Le minitel était bien sûr relié à la ligne téléphonique. Les visiteurs appelaient notre numéro de téléphone, le téléphone sonnait, on décrochait et on "envoyait la porteuse", le visiteur entendait la porteuse (un son continu strident) et connectait son minitel (une touche "connection"). Une fois connecté il pouvait accéder au serveur, ensuite il raccrochait pour libérer la ligne et quelqu'un d'autre pouvait appeler. Le minitel n'est qu'un simple terminal, une sorte de navigateur.
Au début on entendait la sonnerie, on courrait, on décrochait et la personne disait qu'elle voudrait se connecter, on lançait la porteuse. Ensuite on se faisait un petit boitier électronique qui décrochait et envoyait la porteuse tout seul mais du coup si c'était quelqu'un qui voulait parler il se recevait une porteuse en pleine poire ! Donc y avait des horaires et les plus riches avaient une ligne dédiée.
Comme les ordinateurs chauffaient, (ils n'avaient pas de ventilateur) avec mon paternel on avait fait un boitier électronique avec un électro-aimant qui allumait l'ordinateur quand le téléphone sonnait et qui l'éteignait quand la personne partait, une sorte de cloudrun quoi !
Chaque micro serveur était codé à la main et avait souvent un thème, par exemple un thème sur le hacking, un thème sur la prog, jeux etc, quelques pages de texte et quelques pages de type forum. On pouvait également communiquer directement, uniquement entre celui qui avait le micro-serveur et l'appelant.
Les BBS c'est un peu différent. Ils utilisaient aussi les lignes téléphoniques et les modems mais ils communiquaient entre eux pour partager les messages, comme les newsgroups. Ceux qui communiquaient étaient appelés des "nœuds". Les utilisateurs se connectaient à un des noeuds, le plus proche souvent, à l'aide d'un autre micro qui devait avoir un client adapté (et donc pas un terminal comme le minitel). Et à intervalle régulier les noeuds s'appelaient les uns les autres pour partager les messages. C'était un système très résilient, comme les mails et les newsgroups.
[^] # Re: Un autre site solaire
Posté par wilk . En réponse au lien Solar Protocol. Évalué à 5.
Ca me rappelle l'époque des microserveurs minitel dans les années 80, on inversait le modem du minitel 1200/75 bauds, ils étaient branchés sur la ligne de téléphone familiale et on se donnait des heures d'ouvertures pour ne pas saturer la ligne et ne pas faire trop chauffer le micro. Chaque serveur indiquait ces heures d'ouvertures et ça semblait tout à fait normal vu que dans la vraie vie c'est bien comme ça que ça marche à part quelques exceptions comme les pompiers et les hôpitaux.
[^] # Re: Bon événement
Posté par wilk . En réponse à la dépêche Capitole du Libre 2023. Évalué à 2.
Pareil, qu'est-ce que ça fait du bien de retrouver une communauté aussi bienveillante et constructive !
[^] # Re: C'est toujours pas une bonne raison pour abandonner complètement le nucléaire.
Posté par wilk . En réponse au lien Why investing in new nuclear plants is bad for the climate. Évalué à 5.
https://www.revolution-energetique.com/le-nucleaire-est-moins-efficace-que-les-renouvelables-pour-reduire-les-emissions-de-carbone/
[^] # Re: C'est toujours pas une bonne raison pour abandonner complètement le nucléaire.
Posté par wilk . En réponse au lien Why investing in new nuclear plants is bad for the climate. Évalué à 2.
J'ai du rater un épisode dans les commentaires mais on ne manque pas d'exemples d’oppressions dues à la dépendance dans des technologies/logiciels fermées à diverses échelles, pays , collectivités, individus… L'idée reste la même en tout cas.
[^] # Re: C'est toujours pas une bonne raison pour abandonner complètement le nucléaire.
Posté par wilk . En réponse au lien Why investing in new nuclear plants is bad for the climate. Évalué à 2.
Ben si justement le présent montre que c'est le cas (d'où l'intérêt des études sur le sujet). Autant au niveau économique que politique.
A part en Chine peut-être car ils n'ont pas nos contraintes démocratiques et d'alliance avec les voisins.
Tu as raison de ne pas vouloir tout arrêter brusquement mais je crois que tout le monde est d'accord là dessus aujourd'hui même si le curseur est difficile à trouver.
A mon avis on ne va rien décider du tout, c'est un événement quelconque qui décidera, un coup c'était un accident majeur, maintenant c'est le gaz russe. Demain le résultat d'une élection ?
[^] # Re: C'est toujours pas une bonne raison pour abandonner complètement le nucléaire.
Posté par wilk . En réponse au lien Why investing in new nuclear plants is bad for the climate. Évalué à 5.
Je suis juste pas d'accord avec le fait qu'être contre quelque chose implique obligatoirement qu'on ait un biais. Ca peut être au contraire les compétences dans un domaine qui nous amènent à nous positionner et être considéré comme tel.
On (a) subit déjà énormément d'à priori dans notre domaine (le libre) il faut se méfier de ne pas faire la même chose.
[^] # Re: C'est toujours pas une bonne raison pour abandonner complètement le nucléaire.
Posté par wilk . En réponse au lien Why investing in new nuclear plants is bad for the climate. Évalué à 4.
En quoi ce serait un problème ? On est bien anti logiciels privateurs ici, ça n'enlève rien à nos compétences en la matière, bien au contraire.
Quand tu fais du vélo tu connais bien mieux les risques qu'engendre une voiture qu'un automobiliste en général.