Les utilisateurs d'un service d'infrastructure de base (I), ce sont des services de plus haut niveau (S1, S2,…). Les utilisateurs de ces services sont potentiellement les utilisateurs finaux U1 pour S2, U2 pour S2,….
Dans la situation que je décris, il y a de l'argent pour faire évoluer I et S1 mais pas S2. Pour une raison ou l'autre, pour pouvoir faire évoluer S1, il faut faire évoluer I (e.g. limites de mise à l'échelle). Les utilisateurs U2 ne sont organisationnellement pas vraiment en mesure de payer pour S2 (e.g. c'est un service « gratuit ») et son évolution.
Mais oui, au final c'est une décision du management de prioritiser un certains groupe d'utilisateurs (e.g. U1 et leur service S1 qui grandit à 3000% par an) au détriment d'un autre (e.g. U2 et leur service S2 qu'on n'a pas réussi à monétiser suffisamment). On peut aussi voir ça comme prioritiser les nouveaux services (« potentiel prometteurs ») sur les anciens (« on a essayé, c'est pas rentable »). Le management pourrait choisir ses priorités autrement mais à Google j'ai l'impression que c'était (c'est ?) souvent comme ça.
Je ne pense pas que qui que ce soit ai donné comme argument que c'était pour le bien des utilisateurs U2 de casser S2 (bon, parfois il y a un service équivalent S3 et ça peut être une manière de forcer la migration vers ce truc qui est censé être mieux pour eux). Les utilisateurs ne sont pas un groupe uniforme, surtout quand on considère tous les services/logiciels dépendants.
Dans ce contexte, la loi d'Hyrum est un juste un facteur à prendre en compte quand on prend la décision de ce qu'il est important de prioritiser.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
2) Cette loi est utilisée comme raison pour limiter les changements dans l'implémentation des API.
Je vois plutôt ça comme un facteur à prendre en compte consciemment. Je suis d'accord que l'utiliser comme excuse à tort et à travers n'est pas une bonne idée.
l'équipe de développement est au service des utilisateurs (c'est douteux), elle part aussi du principe que les devs ont une forme de responsabilité vis-à-vis de la manière dont les utilisateurs exploitent les fonctionnalités des logiciels (là aussi, c'est douteux).
J'ai du mal à comprendre en quoi c'est douteux. Il y a toujours des contraintes supplémentaires mais fondamentalement, si tu n'écris le logiciel pour les utilisateurs de manière à ce qu'il puisse être utilisé d'une manière raisonnable, je comprend pas trop pourquoi (pour qui ?) tu l'écris.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Disclaimer : j'ai travaillé à Google, y compris sur des projets de réduction de dette technique (y compris avec Hyrum) qui ont mené à casser des trucs pas maintenus mais rien qui ai conduit à l'arrêt d'un service disponible publiquement (que je sache).
C'est amusant de voir que cette loi porte le nom de quelqu'un qui travaille sur la maintenance de logiciels à grande échelle1, dans une entreprise qui a cimetière pour les services qu'elle a tuée.
C'est précisément parce que le travail de maintenance / gestion de dette technique est effectué de manière proactive que des projets sont abandonnés. Sinon on laisse tout pourrir, les vieux trucs continuent de fonctionner mais on fini par ne plus pouvoir rien lancer de neuf de manière efficace.
Dans le cas de Google, il y a plusieurs facteurs et je ne suis pas au courant de tout. Mais de mon expérience, historiquement il y a plein de projets qui ont été lancés, qui s'appuient sur l'infrastructure existante, sans vraiment planifier un budget de maintenance pour le projet lui même sur le long terme. Au fil du temps, l'infrastructure évolue (il y a un budget pour ça) et fini par se retrouver dans une situation où l'API doit changer mais où personne ne veut payer le coût de la mise à jour du côté client/projet.
Plus simplement, les versions majeures et les notifications de futur abandon2 plusieurs versions en avance (parfois plusieurs années) sont utilisées pour ce genre de cas.
Pour les API documentés, bien sûr. Mais il y a plein de trucs pour lesquels c'est pas si simple. C'est précisément le sujet de la loi d'Hyrum.
Par ailleurs, aux dernière nouvelles, Hyrum ne travaille plus à Google.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Ça n'est pas quand même un appel à accumuler de la dette technique?
Si tu lis la page canonique sur le sujet ainsi que le chapitre associé dans le SWE Book, tu peux voir que l'idée c'est pas d'appeler à accumuler de la dette technique de manière indiscriminée mais que, si tu as beaucoup d'utilisateurs, payer ta dette technique peut rapidement coûter cher.
Il n'y a pas de fin. Ce genre de problèmes arrive tout le temps. Si tu veux lire des histoires de gens qui ont eu des problèmes similaires, ont trouvé le client problématique et ont eu des discussions plus ou moins productives avec eux, il y a l'exemple de Netgear et l'université de Wisconsin–Madison ainsi que Wikimedia et une app mobile dans le lien. Wikipedia a aussi une page dédiée à cette classe de problèmes en ce qui concerne NTP.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Non, mais à partir du moment où tu acceptes une requête HEAD, tu censé y répondre correctement (sans contenu notamment). L'implémentation présentée ignore la requête et répond toujours de la même façon.
Donc, non, techniquement c'est pas « un serveur http point » ni même une tentative de l'être. Ça répond à un besoin très spécifique qui utilise une toute petite partie de la spec HTTP. Mais c'est clairement expliqué au début du post et je suis d'accord que chouiner que c'est pas conforme c'est être complètement à côté de la plaque.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Non. Il ne respecte pas le protocole. Si je lui demande un HEAD par exemple il est ko.
Il respecte le protocole de l'énoncé :
il faut qu'elle soit capable de répondre en HTTP une OK 200, sinon le déploiement est considéré comme échoué
Tout le reste osef. Je pense qu'environ aucun serveur HTTP implémente toutes les RFCs de manière complète. Dans ce cas c'est un peu extrême mais le cas d'utilisation est très spécifique. De plus c'est bien expliqué que c'est pour s'amuser, c'est pas pour de la prod et ça a un but pédagogique, y compris pour la personne qui a écrit l'article.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
l'idée de ce genre de sonde doivent simplement répondre à leurs requêtes alors que l'intérêt c'est de vérifier que le logiciel fonctionne
Je pense que c'est un peu plus subtile que ça. Je ne suis pas familier avec Clever Cloud en particulier mais je pense qu'une sonde de « liveness » se doit de vérifier que le service fonctionne indépendamment de toutes dépendances. Si une dépendance dure casse le service mais que le service lui même fait de son mieux, il me semble légitime pour la sonde de répondre "OK". Sinon tu te retrouves à redémarrer le service en boucle, ce qui ne fait qu'intensifier le problème.
On peut (et devrait) avoir des sondes plus poussées qui testent toutes les fonctionnalités. Mais, si un humain est nécessaire pour diagnostiquer une sonde fautive, elle ne devrait pas pouvoir déclencher un redémarrage automatique.
Par exemple : je monte un clone de linuxfr avec le frontend dans un container et la base de données dans un autre. Si la base de données tombe, il est contre-productif de redémarrer le frontend. Donc la sonde de « liveness » du frontend doit dire "OK" même si la base de données est par terre et qu'environ rien ne fonctionne. Le frontend devrait bravement rester debout à servir des erreurs 500 aux utilisateur en attendant que la base de données revienne.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
je n'ai pas trouvé d'exemple sur l'expression du genre dans le design proprement dit d'un langage de programmation
Il y en a pourtant plusieurs. Les deux qui me reviennent à l'esprit sont :
* focalisation sur ce qui est difficile au détriment de ce qui est utile (e.g. « conquérir les math » plutôt que « rendre la programmation plus accessible »)
* focalisation sur les études quantitatives plutôt que qualitatives
C'est expliqué dans la section 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
C'est chouette de voir qu'il y a un effort pour simplifier la vie des contributeurs occasionnels/externes. Ça serait encore plus chouette si on pouvait avoir nos patches reviewés dans un délais de moins de 7 mois :)
Merci pour le travail de maintenance en tout cas.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je pense qu'un changement qui améliorerait la situation pourrait être de vérifier la validité du lien sans le point. Si on a un 404, on vérifie si le lien avec un point fonctionne et on utilise ça à la place le cas échéant. Pour aller plus loin on peut essayer de voir si la phrase autour semble plus ou moins bien formée avec ou sans le point.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Le truc c'est que si t'es le pénible à envoyer ton message gentil, le contrevenant va juste t'ignorer. S'il reçoit la même chose de l'autorité nationale de protection des données (qui ne va vraisemblablement pas faire plus), ça va peut-être le faire réfléchir un poil.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
C'est déjà un système international. L'article Wikipedia a plus d'informations. Par contre ça m'étonnerait qu'on ai un truc compatible en Suisse avant quelques décennies au mieux.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Étant donné qu'il s'agit d'une initiative au niveau de l'UE, il me semblerait logique de regarder plutôt les N% les plus riches à ce niveau qu'au niveau mondial. Cela dit, je suis moi-même sans doute dans les 10% (pourquoi 10% et pas 1% ou 20% ?) les plus riches au niveau de l'UE et je préfèrerais largement être taxé de manière à ce que ça soit redistribué de manière plus équitable / durable que d'être guillotiné ou de mourir d'une « catastrophe climatique ».
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ironie
Posté par Krunch (site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 3. Dernière modification le 27 novembre 2024 à 12:39.
Les utilisateurs d'un service d'infrastructure de base (I), ce sont des services de plus haut niveau (S1, S2,…). Les utilisateurs de ces services sont potentiellement les utilisateurs finaux U1 pour S2, U2 pour S2,….
Dans la situation que je décris, il y a de l'argent pour faire évoluer I et S1 mais pas S2. Pour une raison ou l'autre, pour pouvoir faire évoluer S1, il faut faire évoluer I (e.g. limites de mise à l'échelle). Les utilisateurs U2 ne sont organisationnellement pas vraiment en mesure de payer pour S2 (e.g. c'est un service « gratuit ») et son évolution.
Mais oui, au final c'est une décision du management de prioritiser un certains groupe d'utilisateurs (e.g. U1 et leur service S1 qui grandit à 3000% par an) au détriment d'un autre (e.g. U2 et leur service S2 qu'on n'a pas réussi à monétiser suffisamment). On peut aussi voir ça comme prioritiser les nouveaux services (« potentiel prometteurs ») sur les anciens (« on a essayé, c'est pas rentable »). Le management pourrait choisir ses priorités autrement mais à Google j'ai l'impression que c'était (c'est ?) souvent comme ça.
Je ne pense pas que qui que ce soit ai donné comme argument que c'était pour le bien des utilisateurs U2 de casser S2 (bon, parfois il y a un service équivalent S3 et ça peut être une manière de forcer la migration vers ce truc qui est censé être mieux pour eux). Les utilisateurs ne sont pas un groupe uniforme, surtout quand on considère tous les services/logiciels dépendants.
Dans ce contexte, la loi d'Hyrum est un juste un facteur à prendre en compte quand on prend la décision de ce qu'il est important de prioritiser.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dette technique...
Posté par Krunch (site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 3.
Je vois plutôt ça comme un facteur à prendre en compte consciemment. Je suis d'accord que l'utiliser comme excuse à tort et à travers n'est pas une bonne idée.
J'ai du mal à comprendre en quoi c'est douteux. Il y a toujours des contraintes supplémentaires mais fondamentalement, si tu n'écris le logiciel pour les utilisateurs de manière à ce qu'il puisse être utilisé d'une manière raisonnable, je comprend pas trop pourquoi (pour qui ?) tu l'écris.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ironie
Posté par Krunch (site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 4. Dernière modification le 25 novembre 2024 à 21:29.
Disclaimer : j'ai travaillé à Google, y compris sur des projets de réduction de dette technique (y compris avec Hyrum) qui ont mené à casser des trucs pas maintenus mais rien qui ai conduit à l'arrêt d'un service disponible publiquement (que je sache).
C'est précisément parce que le travail de maintenance / gestion de dette technique est effectué de manière proactive que des projets sont abandonnés. Sinon on laisse tout pourrir, les vieux trucs continuent de fonctionner mais on fini par ne plus pouvoir rien lancer de neuf de manière efficace.
Dans le cas de Google, il y a plusieurs facteurs et je ne suis pas au courant de tout. Mais de mon expérience, historiquement il y a plein de projets qui ont été lancés, qui s'appuient sur l'infrastructure existante, sans vraiment planifier un budget de maintenance pour le projet lui même sur le long terme. Au fil du temps, l'infrastructure évolue (il y a un budget pour ça) et fini par se retrouver dans une situation où l'API doit changer mais où personne ne veut payer le coût de la mise à jour du côté client/projet.
Pour les API documentés, bien sûr. Mais il y a plein de trucs pour lesquels c'est pas si simple. C'est précisément le sujet de la loi d'Hyrum.
Par ailleurs, aux dernière nouvelles, Hyrum ne travaille plus à Google.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dette technique...
Posté par Krunch (site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 4.
Si tu lis la page canonique sur le sujet ainsi que le chapitre associé dans le SWE Book, tu peux voir que l'idée c'est pas d'appeler à accumuler de la dette technique de manière indiscriminée mais que, si tu as beaucoup d'utilisateurs, payer ta dette technique peut rapidement coûter cher.
Voire aussi
https://higherorderlogic.com/programming/2023/10/06/bad-code-isnt-technical-debt-its-an-unhedged-call-option.html
https://apenwarr.ca/log/?m=202306
Et tant qu'on y est https://technology.riotgames.com/news/taxonomy-tech-debt
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: On veut la suite !
Posté par Krunch (site web personnel) . En réponse au lien That’s about 700 times a second. Évalué à 4. Dernière modification le 15 novembre 2024 à 00:37.
Il n'y a pas de fin. Ce genre de problèmes arrive tout le temps. Si tu veux lire des histoires de gens qui ont eu des problèmes similaires, ont trouvé le client problématique et ont eu des discussions plus ou moins productives avec eux, il y a l'exemple de Netgear et l'université de Wisconsin–Madison ainsi que Wikimedia et une app mobile dans le lien. Wikipedia a aussi une page dédiée à cette classe de problèmes en ce qui concerne NTP.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mouai...
Posté par Krunch (site web personnel) . En réponse au lien Un serveur HTTP de moins de 20 Ko [défi technique parce que]. Évalué à 4.
Non, mais à partir du moment où tu acceptes une requête HEAD, tu censé y répondre correctement (sans contenu notamment). L'implémentation présentée ignore la requête et répond toujours de la même façon.
Donc, non, techniquement c'est pas « un serveur http point » ni même une tentative de l'être. Ça répond à un besoin très spécifique qui utilise une toute petite partie de la spec HTTP. Mais c'est clairement expliqué au début du post et je suis d'accord que chouiner que c'est pas conforme c'est être complètement à côté de la plaque.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mouai...
Posté par Krunch (site web personnel) . En réponse au lien Un serveur HTTP de moins de 20 Ko [défi technique parce que]. Évalué à 7.
Il respecte le protocole de l'énoncé :
Tout le reste osef. Je pense qu'environ aucun serveur HTTP implémente toutes les RFCs de manière complète. Dans ce cas c'est un peu extrême mais le cas d'utilisation est très spécifique. De plus c'est bien expliqué que c'est pour s'amuser, c'est pas pour de la prod et ça a un but pédagogique, y compris pour la personne qui a écrit l'article.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Super avec un mais
Posté par Krunch (site web personnel) . En réponse au lien Un serveur HTTP de moins de 20 Ko [défi technique parce que]. Évalué à 4. Dernière modification le 01 novembre 2024 à 10:49.
Je pense que c'est un peu plus subtile que ça. Je ne suis pas familier avec Clever Cloud en particulier mais je pense qu'une sonde de « liveness » se doit de vérifier que le service fonctionne indépendamment de toutes dépendances. Si une dépendance dure casse le service mais que le service lui même fait de son mieux, il me semble légitime pour la sonde de répondre "OK". Sinon tu te retrouves à redémarrer le service en boucle, ce qui ne fait qu'intensifier le problème.
On peut (et devrait) avoir des sondes plus poussées qui testent toutes les fonctionnalités. Mais, si un humain est nécessaire pour diagnostiquer une sonde fautive, elle ne devrait pas pouvoir déclencher un redémarrage automatique.
Par exemple : je monte un clone de linuxfr avec le frontend dans un container et la base de données dans un autre. Si la base de données tombe, il est contre-productif de redémarrer le frontend. Donc la sonde de « liveness » du frontend doit dire "OK" même si la base de données est par terre et qu'environ rien ne fonctionne. Le frontend devrait bravement rester debout à servir des erreurs 500 aux utilisateur en attendant que la base de données revienne.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mouai...
Posté par Krunch (site web personnel) . En réponse au lien Un serveur HTTP de moins de 20 Ko [défi technique parce que]. Évalué à 5.
Le golf est un hobby valide. Critiquer le hobby des autres sans même essayer de participer me semble moins valide.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mouai...
Posté par Krunch (site web personnel) . En réponse au lien Un serveur HTTP de moins de 20 Ko [défi technique parce que]. Évalué à 5.
Tu me dira quand t'aura trouvé un binaire Bash qui fait moins de 20 Ko.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: serait il possible de m'expliquer
Posté par Krunch (site web personnel) . En réponse au lien Feminism in Programming Language Design. Évalué à 3.
Il y en a pourtant plusieurs. Les deux qui me reviennent à l'esprit sont :
* focalisation sur ce qui est difficile au détriment de ce qui est utile (e.g. « conquérir les math » plutôt que « rendre la programmation plus accessible »)
* focalisation sur les études quantitatives plutôt que qualitatives
C'est expliqué dans la section 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# merci
Posté par Krunch (site web personnel) . En réponse au lien Feminism in Programming Language Design. Évalué à 3.
Le papier est intéressant. C'est dommage que beaucoup s'arrêtent au titre.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Sans image fixe
Posté par Krunch (site web personnel) . En réponse à la dépêche img, le cache d’images sur LinuxFr.org. Évalué à 1.
Moi ce que je comprend c'est que tu as du mal d'écrire du bon alt text.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# incapable de mentir ?
Posté par Krunch (site web personnel) . En réponse au lien Ils nous mentent. Évalué à 6.
Dixit le type qui a écrit quatre livres de fiction…
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# faciliter les contributions externes
Posté par Krunch (site web personnel) . En réponse à la dépêche img, le cache d’images sur LinuxFr.org. Évalué à 6.
C'est chouette de voir qu'il y a un effort pour simplifier la vie des contributeurs occasionnels/externes. Ça serait encore plus chouette si on pouvait avoir nos patches reviewés dans un délais de moins de 7 mois :)
Merci pour le travail de maintenance en tout cas.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: LOL
Posté par Krunch (site web personnel) . En réponse au journal LinuxFr.org : première quinzaine d'octobre 2024. Évalué à 4.
La modération t'a insulté ?!
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Une image vaut mille mots
Posté par Krunch (site web personnel) . En réponse au lien discours retardant l'action climatique. Évalué à 2.
Est-ce que 4473 mots ça te convient ? https://www.cambridge.org/core/journals/global-sustainability/article/discourses-of-climate-delay/7B11B722E3E3454BB6212378E32985A7
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # TIL
Posté par Krunch (site web personnel) . En réponse au message un éditeur de texte avec mot de passe?. Évalué à 3.
La documentation officielle est ici : https://vimdoc.sourceforge.net/htmldoc/editing.html#encryption
Le wiki explique aussi comment faciliter l'utilisation de gpg (entre autres) avec vim : https://vim.fandom.com/wiki/Encryption
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Une image vaut mille mots
Posté par Krunch (site web personnel) . En réponse au lien discours retardant l'action climatique. Évalué à 1.
Je préfère lire l'étude.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# toto découvre les DRM
Posté par Krunch (site web personnel) . En réponse au journal Programme qui se vérifie lui-même pour voir s'il a été modifié. Évalué à 0.
L'article wikipedia correspondant est https://en.wikipedia.org/wiki/Anti-tamper_software
Les articles connexes sur le cracking ainsi que les archives de phrack (en particulier à partir du numéro 49) peuvent peut-être t'intéresser (bon c'est plutôt orienté attaques évidemment). J'apprécie en particulier la section Notable payloads de l'article Wikipedia sur la Copy Protection.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Visiblement ce n'est pas propre à la tribune
Posté par Krunch (site web personnel) . En réponse à l’entrée du suivi les liens qui se terminent par un point ne sont pas « linkifié » correctement. Évalué à 2 (+0/-0). Dernière modification le 02 octobre 2024 à 14:32.
Ça me semble vraisemblable, oui.
Je pense qu'un changement qui améliorerait la situation pourrait être de vérifier la validité du lien sans le point. Si on a un 404, on vérifie si le lien avec un point fonctionne et on utilise ça à la place le cas échéant. Pour aller plus loin on peut essayer de voir si la phrase autour semble plus ou moins bien formée avec ou sans le point.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ça arrive...
Posté par Krunch (site web personnel) . En réponse au message Quel site utiliser pour signaler une adresse email fuitée ?. Évalué à 6.
Le truc c'est que si t'es le pénible à envoyer ton message gentil, le contrevenant va juste t'ignorer. S'il reçoit la même chose de l'autorité nationale de protection des données (qui ne va vraisemblablement pas faire plus), ça va peut-être le faire réfléchir un poil.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: je doute que ce soit la fin de l'IBAN
Posté par Krunch (site web personnel) . En réponse au lien C’est la fin de l’IBAN : les banques françaises s’allient pour simplifier les virements avec Wero. Évalué à 2.
C'est déjà un système international. L'article Wikipedia a plus d'informations. Par contre ça m'étonnerait qu'on ai un truc compatible en Suisse avant quelques décennies au mieux.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# ça dépend
Posté par Krunch (site web personnel) . En réponse au message Quel site utiliser pour signaler une adresse email fuitée ?. Évalué à 4.
Selon le pays concerné, je passerais par l'Autorité de protection des données, le Préposé fédéral à la protection des données et à la transparence ou l'Information Commissioner's Office. Ils ont tous un formulaire adéquat. Pour les autres pays, je sais pas.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: oui mais non
Posté par Krunch (site web personnel) . En réponse au lien il vous reste 2 semaines pour signer la pétition européenne pour taxer les grandes fortunes. Évalué à 4.
Étant donné qu'il s'agit d'une initiative au niveau de l'UE, il me semblerait logique de regarder plutôt les N% les plus riches à ce niveau qu'au niveau mondial. Cela dit, je suis moi-même sans doute dans les 10% (pourquoi 10% et pas 1% ou 20% ?) les plus riches au niveau de l'UE et je préfèrerais largement être taxé de manière à ce que ça soit redistribué de manière plus équitable / durable que d'être guillotiné ou de mourir d'une « catastrophe climatique ».
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.