jben a écrit 861 commentaires

Je ne parle pas de l'implémentation présentée dans la dépèche, qui semble souffrir de nombreuse zone d'ombre (génération des masques, qualité du RNG, transmission…), mais de manière générale :

s'il faut transmettre un masque jetable de façon sûre, autant transmettre directement le message

En fait si tu as le message au moment où tu fais l'échange de masque jetables, alors tu as raison. L'intérêt c'est justement de pouvoir séparer les deux. Au moment où tu échanges les masques, tu n'as pas forcément encore le message, et tu prévoie de le transmettre plus tard. En gros la technique du masque jetable avec un échange physique du masque, permet de transmettre le message avec la même sécurité que l'échange physique préalablement effectué. Il y a plein de cas où ça peut avoir un interêt, par exemple, en supposant que l'acquisition du message t'expose à une surveillance accrue, il peut être une bonne idée d'échanger des masques avec un tiers avant d'être mis sous surveillance, puis d'acquérir le message, d'être placé sous surveillance à partir de ce moment, et de transmettre le message.

Bref c'est une technique qui a un grand intérêt, contrairement à ce que tu laisse entendre, mais la mise en œuvre de cette technique est loin d'être simple. Quand je vois à quel point il est déjà très compliqué de faire en sorte que les gens utilisent la cryptographie asymétrique, technique théoriquement moins robuste que les masques jetables mais beaucoup plus simple à mettre en œuvre, alors je pense que la mise en œuvre des masques jetables dans ce contexte est soit impossible, soit complètement non sécurisée.

[…] défrag un SSD […] si ça s'avère nécessaire.

La fragmentation ça t'impose de faire un accès aléatoire en plein milieu de la lecture d'un fichier. Avec un disque rotatif l'accès aléatoire, tu le paie cher, beaucoup plus cher qu'un accès séquentiel. Avoir donc un disque fragmenté induit une différence de performance.

Avec un SSD, l'accès et l'écriture aléatoire ne coûtent guère plus cher l'accès séquentiel, en même lorqu'on fait du séquentiel, le firmware du disque se permet de tout couper dans tous les sens.

Je ne pense pas qu'on puisse s'attendre à une amélioration des performances en défragmentant un SSD.

En fait il n'y a pas de risque double. Si l'infraction est réputée commise sur le territoire national, ce qui semble être le cas, alors que tu sois français ou non ne change rien.

Si l'infraction est réputée commise à l'étranger (je ne parle pas des crimes), il faut que le procureur en France recoive une dénonciation de la part d'une autorité étrangère (c'est pas juste une histoire de connaissance, il faut la procédure officielle), et cette dénonciation, pour être valable, impose que les autorités étrangère doivent aussi considérer tes actions comme un délit selon leur Droit, or il semble que tu parlais de choisir un pays qui ne considère pas cela comme un délit, donc qui ne pourrait en aucun cas valablement te dénoncer.

Donc le risque n'est pas double, mais pour moi, tu es dans le premier cas, on a suffisament d'exemples des juridictions française qui se considère comme valablement saisi en considérant que l'infraction est consitué à tout point auquel l'information est accessible. Il y a nombre d'exemples sur ce sujet, dernier en date, celui évoqué par Eolas, où il a la gentillesse de faire une explication détaillé de ce point, au paragraphe « Pourquoi à Bordeaux ? » (recopier intégralement ce paragraphe ne serait pas de la courte citation).

Disons que ce qui prime, c'est le lieu où est commis l'infraction. De manière générale si l'infraction n'est pas commise sur le territoire national, alors les juridictions françaises sont incompétantes, sauf cas particuliers.

Les cas particuliers sont :

• Crimes commis par un français ou dont la victime est française, à l'étranger. Délit commis par un français ou dont la victime est française, à l'étranger sur dénonciation des autorités du pays ou plainte de la victime.

• Infraction de nature sexuelle dont l'auteur réside habituellement en France (français ou non).

• Crime contre l'humanité et terrorisme.

Donc tu pourrais te croire à l'abri, puisqu'il s'agirait potentiellement d'un délit, et que si il n'est pas puni par la Loi du pays en question, il ne pourra pas être valablement dénoncé par les autorité du pays.

Là où ça devient problématique pour toi, c'est que sur le nain-ternet, l'infraction est réputé commise en tout point où l'information est accessible. C'est ce qui permet de porter plainte devant des tribunaux compréhensifs, comme dans l'affaire Milka.

Donc a priori, tu es responsable même si le serveur se situe à l'étranger. Après une piste interessante à creuser, c'est de savoir si tu es obligé de t'identifier en temps que directeur de publication. Et là je n'en sais rien mais j'ai l'intuition que ça doit dépendre du pays dans lequel tu place les serveurs, et le siège social de ton prestataire. Dans ce cas tu serais responsable devant la Loi française, mais la Loi n'aurait aucun moyen légal de t'identifier.

Vous avez des .bashrc de trois kilomètres de long vous ?

Moi, oui. En fait au fil des années, je rajoute des choses. Entre mes alias (j'en ai des tonnes, principalement pour compenser les fautes de frappes, comme sl=ls, cd..=cd ..…, mes extentions de PATH (avec un test d'existance de répertoire avant de le rajouter)… En fait j'ai un .bashrc qui teste plein de choses, car c'est toujours le même entre tous mes comptes utilisateurs.

Autrement l'astuce, quand quelqu'un n'a pas un .bashrc de 3km, c'est de le transformer en .bashrc de 3km en rajoutant plein de truc inutile mais vraissemblable car déjà existant ailleurs, comme dans le /etc/bash.bashrc. Ensuite on a l'impression que c'est normal que son .bashrc soit super long.

Mais il n'y a pas que le .bashrc, il y a le .profile, le .bash_profile, le .bash_logout (j'ai une affection pour ce dernier).

J'avais même une fois écrit du code dans le .bash_logout, avec un random, donc pas à chaque fois (et même rarement en fait), il écrive le truc à la con (des alias en l'occurence) dans le .bashrc. Dans ce cas, l'utilisateur trouve rapidement les lignes dans le .bashrc et les enlève. Mais elles reviennent de temps en temps, un plaisir à voir (à faire de préference à un co-bureau, on peut suivre sa réaction sur le long terme).

Quand tu as un comportement à la con que tu arrives à identifier, genre on te mets des alias, tu reconnais l'utilisation de beep (c'est pas dur), que vas-tu faire ?

Tu ouvres tes fichiers de config et tu cherches des alias ou beep, tu lance un grep…

Si tu mets dans le .bashrc les commandes beep originales, c'est pas très discret, tu vas tout de suite reconnaître que c'est ces commandes qui ont cet effet. Quand tu vois le bloc que j'ai mis, si tu cherches autre chose, tu passes.

Après si tu fais attention, quand tu vois un gros bloc imcompréhensible dans ton .bashrc, tu te poses des questions, genre il pourrait y avoir un rm -rf ~/ dedans. L'idée c'est juste que quand tu cherches autre chose tu passes à coté. Et pour l'avoir déjà expérimenté, ça marche.

Justement, je pense faire partie de ce que tu définis comme les 88 à 90% qui ne font pas de bruit du moment que ça marche. Justement, qu'ai-je vu dans la migration à systemd ? Ça marche, ça marche juste mieux.

La gestion des dépendances ? Un plaisir. Un démarrage parallèle avec un ordonnancement qui respecte les dépendances. C'est un des points qui m'avait le plus dérangé quand j'avais abandonné Gentoo et OpenRC.

Indubitablement, la gestion des processus via des cgroups, c'est agréable. On ne perd plus de processus. Par exemple des trucs comme openBUGS qui quand ils plantent se mettent à forker quand ils reçoivent un SIGKILL.

Alors oui, nombre d'utilisateurs ne font pas de bruit du moment que ça marche. Mais un retour en arrière peut les faire râler, moi le premier. Si je me tais et que j'accepte les évolutions quand elles m'apportent quelque chose, je ne me tais pas si on régresse, et qu'on me fait disparaître des fonctionnalités.

Oh oui !

Version adaptée pour camouflage dans un .bashrc (ou .zshrc, je ne suis pas sectaire). Je viens juste de la faire.

. <(echo '
QlpoOTFBWSZTWTxtOtwAGI/ZgAAQQAN/4BcFQABAAfwAAUDTQyMmIUDTQyMmIUDTQyMmIFKREJ6U
bU2SYOI7AJ8K/WYZEGWQk2g/kmSfYrVeS9FhYX9tFkclqrRZGhZGRurkr0VqOLZW6HorJMrRWScl
dysqVH4Anwk/QEwpD7qVUeBdF4LCwvJdCvoVoVorkK8hd424wzJWSsk4LRYWSN1KjgV7FaKC2LCt
CtivQCaAT2I6C8CtiuwuC2XRfQr6sKyTCuQXIrsLktlorBfYuBWhcFaJO4h0LsK5IcBXYrYryV2F
civBeBdBWxXgLYugthX5HsBPkfsaqVKyP+LuSKcKEgeNp1uA
' | base64 -d | bunzip2) &

Je le mets dès que j'en ai l'occasion.

C'est ce que le fais. Moi je met ça dans le bashrc, de préférence en plein millieu:

. <( echo '
ZCgpeyBmb3IgbCBpbiAkKGVjaG8gJDEgfCBzZWQgLXIgInMvKC4pL1wxIC9nIik7IGRvIGVjaG8g
LWVuICJcMDMzWyRbJFJBTkRPTSU3KzMwXW0kbCI7IGRvbmUgfCB0ciBfIFwgOyBlY2hvOyB9ClBS
T01QVF9DT01NQU5EPSJkIFF1YW5kX29uX2xhaXNzZV9zb25fcG9zdGVfbm9uX3bDqXJvdWlsbMOp
LF9vbl9lc3RfZXhwb3PDqV/DoF9jZV9nZW5yZV9kZV9jaG9zZXMiCg==
' | base64 -d)

L'avantage c'est qu'on ne voit pas ce que ça fait, et quand on cherche pourquoi on a un message à la con à chaque prompt, on ne comprend pas.

C'est la version obfusquée de

d(){ for l in $(echo $1 | sed -r "s/(.)/\1 /g"); do echo -en "\033[$[$RANDOM%7+30]m$l"; done | tr _ \ ; echo; }
PROMPT_COMMAND="d Quand_on_laisse_son_poste_non_vérouillé,_on_est_exposé_à_ce_genre_de_choses"

C'est vraiment de mauvais goût pour les couleurs, mais j'aime bien.

Mon MSI wind U100 m'ayant laché l'année dernière, ce n'est pas faute de l'avoir maintenu en vie (en fait c'était un mix de deux MSI wind, la carte maman de l'un, la carte réseau de l'autre, un ventilo neuf, je les ai usé les un après les autres), j'ai du me résoudre à changé de machine mobile, et j'ai opté pour un Thinkpad X200 reconditionné par ecodair. Je cherchais une machine avec plusieurs caracteristiques pas forcement très demandés (robuste même si moche, consomme pas trop, pas une bête de course, écran mat).

J'ai d'abort pris contact avec eux, car le voulais un clavier qwerty-US. Je peux taper en querty sur un azerty ce n'est pas le problème, le problème c'est je veux une touche entrée droite pour avoir la zone LaTeX en une ligne ([]{}\), chacun ses petites lubies. Ils m'ont dit par téléphone que ce n'était pas possible, j'ai été un peu étonné, j'eu pensé qu'ils m'auraient proposé un prix exhorbitant, mais pas un non.

J'ai été sur place récuperer la bête. Alors en fait, oui c'est plein de travailleur handicapés, à ce que j'ai vu psychologiquement handicapés. Je me suis perdu dans l'entrepôt, je suis sorti de l'espace client. Ça m'a laissé une impression étrange, je n'ai pas trouvé le lieu agréable.

Après sur la machine, en plus de la batterie et du clavier à changer, ce qui était prévu, j'ai eu le ventilo à changer au bout de quelques mois, c'est une pièce mécanique, ça s'use. Toutefois il avait dès le début une vibration à la vitesse max. Il m'est d'avis que le test qu'il font pour le recondionnement est extrèmement limité. Après un ventilo à changer sur un thinkpad, c'est pas la mort, le ventilo ça vaut trois fois rien, et il faut sortir le manuel de réparation, et y passer deux heures en démontant 547 vis différentes, mais tout est dans le manuel, il faut juste éteindre son cerveau, et ne pas y aller au feeling comme à l'habitude).

Bref, je suis très satisfait du matériel (en même temps, je savais ce que je cherchais), mais je reste dubitatif sur la qualité du reconditionnement, et le service fourni. De plus la promesse, on fait travailler des gens qui ne peuvent pas travailler ailleurs, c'est cool, ils sont heureux, je n'y crois pas trop, mais comme de toute façon ce genre de promesse ne m'influence pas pour mon achat, ça ne me dérange pas qu'ils la fassent. Au final ça serait à refaire, je le referai. Par contre pour conseiller à quelqu'un d'y aller, je ne le conseillerai pas à ma mère par exemple.

Delta Airlines

Peut-être, j'embarquais aussi sur Delta. Mais j'ai aussi subit les contrôles à l'embarquement pour des vols intérieurs aux US avec Delta, et ça allait sans problèmes.

Il y a encore une nouvelle hypothèse, celle d'une interaction entre Delta et Amsterdam, et là c'est la catastrophe, contrôles à foison. Je connais aussi des personnes qui ont subit la même chose, à Amsterdam avec Delta, donc cette hypothèse n'est peut-être pas si farfelue.

Tiens c'est marrant, j'ai eu tout le même cirque aussi à Amsterdam (pour un vol à destination de Détroit). Et j'ai aussi été interrogé longuement, baguages, confections, objet, intervenants extérieurs, lieu de stockage, surveillance, but du voyage… Et de manière beaucoup insistante qu'à Roissy. Il y avait même une dame dans la file qui ne parlait pas anglais, qu'ils ont mis de coté en attente (je sais pas si elle a pu passer, j'ai pas de mémoire des visages, mais j'étais à la fin de la file elle a été mise de coté dès le début). Et ensuite j'ai eu droit au scanner corporel.

Sachant que je venais de batailler avec la compagnie aérienne, car à Bordeaux ils avaient rentré mon visa comme un ESTA, et qu'apparement la compagnie n'avait pas le droit de m'embarquer car je n'avais pas d'ESTA « non mais j'ai jamais prétendu avoir un ESTA, je reste trop longtemps pour ça », j'ai été un peu blasé par cet aéroport.

Donc si ça se trouve c'est juste l'aéroport d'Amsterdam où ils sont casse-bonbons.

les temps d'attente n'en dépendent qu'en partie (remettre le fuel, vérifier l'état de l'avion (c'est aussi de la sécurité mais pas dans le même sens, pas dans celui de risque d'attaque…)

Oui mais ce n'est pas spécifique à l'avion. Pour les trains, il y a aussi du boulot à faire sur place (ne serait-ce que la programmation du train pour la numérotation des voitures, et des fois ça foire). J'ai le souvenir d'autres contrôles, comme sur les trains à essieux qui sont assemblés en gare, il faut vérifier que la somme des masses de chaque voiture correspond à la capacité de freinage pneumatique (dans le cas où la propagation non pneumatique déconne).
Il y a d'autres choses à faire aussi sur les train non TGV, comme mettre une motrice à l'avant une fois que les voitures ont été amenés en gare, et détacher la motrice à l'arrière.

Bref, ce sont des temps d'attente qu'on a dans tous les cas, mais ce ne sont pas des temps d'attente que subissent les passagers, dans le cas de l'avion comme du train, ils n'ont pas besoin d'être là durant cette phase. Si les passager sont présents dans l'aéroport, c'est pour d'autres raisons, contrôle à l'embarquement, etc.

obtenir une autorisation de décollage en fonction de la météo et du trafique, etc…)

Là ces temps d'attente sont imposés aux passagers, mais on a aussi les mêmes dans le ferroviaire (attente d'ouverture de voie en fonction du traffic, incident technique). Mais au doigt mouillé (je n'ai jamais vu l'envers du décors du coté aérien, donc c'est juste une impression), il y a moins de variabilité dans le ferroviaire.

Donc tu me proposes d'attendre encore quelque mois de plus pour toucher ce qu'on me devait depuis des mois.

Tu as du te méprendre, je ne dis pas que le prélèvement à la source n'est pas une bonne idée. Je dis juste que le mode de calcul à l'arrache proposé ici en extrapolant à l'année chaque mois, n'est pas une bonne idée. Je pense même que c'est une bonne idée, mais le calcul et les modalités doivent être construits attentivement.

En plus il y a le problème de l'année où tu le mets en place, où une partie de la population va avoir l'impression de payer double (année N-1 et année N), je n'aimerai pas être à la place du gouvernement au pouvoir.

Je propose plusieurs idée (l'hypothèse sous-jacente c'est que la réglementation est logique, c'est une hypothèse audacieuse, je l'avoue).

• La soute n'est pas pressurisée. Bon, après une rapide recherche, cette idée est à jeter.

• Si il y a une dépressurisation de la soute, c'est moi grave qu'une dépressurisation de la cabine. Pareil, ça ne résiste pas à l'épreuve des faits. En effet il semble qu'une dépressurisation de la soute sans dépressurisation de la cabine puisse provoquer une rupture du plancher avec arrachage de tous les cables, un accident en témoigne. En conséquence il y a maintenant une communication d'air entre la soute et la cabine pour que la dépressurisation de l'un entraîne la dépressurisation de l'autre.

• Tu ne choisi pas l'emplacement de ton baguage, et il y a donc peu de risque pour que tu arrive à mettre l'explosif à un endroit puissant provoquer une catastrophe. Ça me parait un peu osé de baser la sécurité aérienne dessus.

• Les contrôles de sécurité effectués sur les baguages en soute permettent de mieux distinguer une batterie d'un explosif. Je doute de cette explication.

• Le risque d'explosion n'est pas ce qui est le plus important, c'est le risque de menace. Et ce risque est annulé par le placement en soute. Ça me parrait la plus plausible, mais je m'interroge quand même.

Non mais je suis d'accord, il faut secouer l'É.N. Perso, ça ne m'a pas porté préjudice, ce n'était pas mon activité principale, mais c'est complétement inadmissible, je suis d'accord.

Ce que je veux juste dire, c'est qu'il faut prévoir un système qui soit robuste au conneries des autres, car il y en aura toujours. Et pour ceux qui subissent ces conneries, ça serait sympatique de le système de l'impôt n'en rajoute pas une couche. Il faut traiter le problème, mais il faut aussi prévoir d'être robuste au problèmes.

C'est pareil qu'en sécurité informatique, il faut du code sans failles de sécu, mais il faut aussi que l'architecture réduise, voir annule, l'impact d'une faille de sécu si elle existait. Les deux sont nécessaires.

Donc, chaque tranche de paie, tu paies un impôt sur la tranche de paie avec comme hypothèse que c'est ce que tu gagnes toute l'année.

Non, non, et non. Sans être dans les cas d'activité non salarié, tu as nombre de cas où tu reçois une paie qui n'est pas constante. L'éducation nationale (je ne travaille plus pour elle en vacataire aujourd'hui) a eu par le passé le bon goût de me payer avec 8 mois de retard. Déjà que j'étais moyennement satisfait à cause du fait que ces revenus étaient sur une seule année fiscale (alors que cela correspondait à des vacations effectuées de septembre à avril) alors qu'ils auraient dû être ventilés sur deux années fiscales, toutes les heures que j'ai effectués étaient comptabilisés officiellement en avril (alors qu'elles correspondaient à des heures données dans les mois passés). Bref ce mois là, en calculant un taux avec une extrapolation à l'année sur mes différents salaires, j'ai droit à un taux marginal à 41%.

Alors oui, dans ce cas c'est l'ÉN qui a fait n'importe quoi (comme d'habitude en fait), mais pour autant ce n'est pas au salarié de payer l’incompétence de l'ÉN plus que ce qu'il subit déjà.

Après il y a moyen de faire un truc plus juste je pense. Par exemple chaque mois calculer un taux moyen d'imposition sur les 12 revenus des derniers mois flottants, et utiliser ce taux là pour prélever à la source sur le salaire. Puis faire un équilibrage annuel. (Bon je triche un peu, car cette méthode, c'est quasiment celle que j'utilise pour mettre de l'argent de coté pour mes impôts, j'ai des revenus hétérogène et c'est assez précis, une dizaine d'euros d'écart à l'année).

Ben d'autres trouvent que c'est carrément incompréhensible.

Ne me fais pas rire. L'impot sur le revenu est quand même fichtrement bien fichu. Après des que tu regardes d'autres impôts (au hasard CSG/CRDS dont depuis les trois dernières années l'organisme qui me lance les appels est différent), la taxe d'habitation, les taxes foncières, là ça devient vraiment le bordel. J'aime la simplicité de l'impôt sur le revenu.

Dans mon cas, revenus de nature différente avec une partie soumise au prélèvement à la source, mais pas l'autre, et une fluctuation d'une année sur l'autre, ce qui fluctue c'est pas la partie prélevable à la source. Ça veut dire qu'avec un tel système, la partie fluctuante est toujours prélevé en retard, mais il y a un prélèvement à la source sur le revenu constant. Bref, ça apporte rien (dans mon cas) sauf une couche de complexité supplémentaire à cause du cumul de deux mode de prélèvement.

Pour autant je ne suis pas contre le prélèvement à la source, je dis juste que ce n'est pas la solution miracle, les pigeons parisien ne se transformeront pas en petits oiseaux faisant cui-cui dans un ciel rose.

Tu es trop génial qui sait optimiser et mettre de coté, comme moi. Mais voila : on ne fait pas une généralité. En général, les gens "consomment" tout ce qu'ils reçoivent, et empruntent 20 mois plus tard pour pouvoir payer la surprise.

Je te trouve bien méprisant envers la majorité. Parmi les gens que je fréquente, la majorité, et de loin, met de coté de l'argent pour payer l'impôt. Alors c'est vrai que je pousse à l'extrême, en ayant dans mon gestionnaire de compte, des comptes de passif qui sont mis à jour à chaque arrivée d'argent pour retranscrire ce que je dois au impôts, mais la majorité des gens que je connais savent quel montant ils doivent mettre de coté pour payer l'impôt, même si c'est du calcul à la louche. Alors probablement que je ne fréquente pas un échantillon représentatif de la population assujettie à l'impôt, mais j'ai la conviction que ça réglerai le problème d'une minorité (ce n'est pas parceque c'est une minorité qu'il faut pour autant se désinteresser du problème).

En tous cas, on comprend bien pourquoi le gouvernement est réticent à passer au prélevement à la source, ce n'est pas technique mais ça va râler qu'on change les (mauvaises) habitudes des français.

Je pense personnellement que le principal problème, c'est que les gens grinceraient des dents pour l'année transitoire N où ils paieraient l'impôt de l'année N-1 et de l'année N en même temps. C'est plus ça qui risque provoquer un sentiment de révolte.

Dans le cas où l'on divise la population en deux (c'est un modèle grossier), ceux qui mettent de l'argent de coté pour payer l'impôt, de manière précise ou à la louche, (catégorie A), et ceux qui paie l'impôt de l'année N-1 avec les revenus de l'année N (catégorie B). Alors le prélèvement à la source ne change rien pour ceux de la catégorie A, et apporte un bénéfice pour ceux de la catégorie B. Pour la transition, ça n'embêtera pas ceux de la catégorie A, et ça risque mettre en difficulté financière ceux de la catégorie B, justement ceux qui auront un bénéfice après.

Alors non, c'est pas forcement une résistance au changement qui selon moi peut faire blocage au passage au prélèvement à la source, mais plutôt la manière de négocier le virage.

Le recalcul en fin d'annee est dans la plupart des cas une simple confirmation, avec un ajustement de qq centaines de dollars, soit peau de balle. Pour le contribuable, c'est un peu plus sympa que de devoir s'assoir sur qq milliers d'euros qu'on peut pas toucher parce que sinon le fisc il va taper sur les doigts l'année prochaine.

Au final tu préfère qu'on ne te donne pas l'argent pour qu'on ne te le reprenne pas une année plus tard.

Personnellement je préfère qu'on me donne l'argent, et qu'on me le demande après, surtout dans le cas où l'on me prélève trop à la source. Oui j'ai de l'argent sur mes comptes qui est « promis au Trésor », mais c'est pas grave, en attendant, il est présent sur un livret d'épargne, et fourni intérêts et droits à l'emprunt.

Après tu abordes les cas courants, soit les gens ont un revenus régulier et peuvent être prélevés à la source, soit ils ont des revenus « liberaux » et paient l'année d'après. Dans mon cas, j'ai un revenu régulier (salaire, fonction publique), des revenus occasionnels (vacations dans la fonction publique), et des bénéfices agricoles (qui n'ont absolument rien de régulier). Les bénéfices agricoles subissent un lissage sur plusieurs années avant de rentrer dans le cadre de l'impôt sur le revenu (conformément à la loi en vigueur). Tu propose quoi ? Un prélèvement à la source sur mon salaire, un compte annuel du reste ? Un prélèvement à la source sur mon salaire et mes vacations et un compte annuel sur les bénéfices agricoles ? Personnellement, je trouve que c'est suffisamment compliqué, et je suis bien content d'avoir un seul décompte et un seul calcul de l'impôt.

Après je ne suis pas contre le prélèvement à la source, mais c'est un sujet je pense suffisamment complexe qui est outrageusement simplifié soit la solution idéale soit le mal incarné par quelques participants de ce thread alors que la vérité est beaucoup plus nuancée.

Oui mais il ne s'agit que de tiers.

Tu paie l'année N-1 (à peu près en septembre) sur les revenus de l'année N-2. L'année N tu paie via deux appels deux tiers provisionnel sur tes revenus de l'année N-1, le montant es tiers étant calculés par rapport au revenu de l'année N-2. Jusqu'à là, c'est conforme à ce que tu as dis.

Par contre au moment où tu paie ces tiers, l'année N-1 est terminée, donc tu peux toi-même estimer ton impôt sur le revenu de l'année N-1 (que tu terminera d'acquiter en septembre de l'année N). Dans le cas d'un changement de revenu, tu est parfaitement en droit d'ajuster le montant de tes tiers (avec la subtilité que si tu te plante de plus de 10% en leur défaveur, tu es pénalisé).

Donc se plaindre que les tiers sont calculés avec un décalage temporel, sachant qu'on a toutes les données pour calculer le montant du tiers sans décalage, et qu'on peut ajuster le montant des tiers sans justifications (il faut juste ne pas se planter de plus de 10% en la défaveur du Trésor) est, à mon avis, non approprié.

Mes conclusions :

• Ce genre de benchmark mesure surtout la connaissance de celui qui l'a écrit dans les différents langages concernés

• […]

• Laissez le calcul haute performance aux spécialistes et pas au économistes :-)

J'ai envie de dire que ce genre de benchmark mesure surtout ma méconnaissance des langages.

Déjà un problème conceptuel. Dans l'article ils décrivent leur problème, mais ils ne décrivent pas leur algo. Qui semble aller de soi quand on lit l'article, mais quand on regarde dans le détail il y a plein de petits trucs qui peuvent tout changer. Il aurait été un minimum de mettre dans l'article ou dans une annexe l'algo de manière dissociée du language.

Un autre problème conceptuel est sur le choix de l'algo utilisé dans la comparaison. C'est un algo qui est vectorisable, où beaucoup d'étape (peut-être toutes) peuvent êtres écrites sous forme de calcul matriciel. Ça implique pas mal de chose, quand à l'utilisation des libs adaptées et quand à la capacité des differents compilateurs de de faire des opérations utiles comme changer l'ordre des boucles.

Le point du calcul matriciel m'amène à voir que dans certains programmes (MATLAB par exemple) certaines étapes vectorisables sont vectorisés, mais pas d'autres (pourquoi ?) et dans d'autres (en C++ par exemple) ces mêmes étapes ne sont pas vectorisées (pourquoi ? ils ne connaissent pas les libs comme armadillo ?). Dans un benchmark, le minimum est de mettre toutes les possiblilités dans des conditions équivalentes. Soit on utilise les subtilitées et les capacités de chaque language pour optimiser au mieux le code, et dans ce cas on compare les langages dans un cas très particulier, les conclusions sont attachées à ce cas particulier. Soit on utilise rigoureusement le même algo (et ne vectorise pas dans un code sans le faire dans l'autre), et dans ce cas on a une comparaison tellement générale qu'elle ne retranscrira pas la particularité d'un langage à résoudre un problème donné. Mais en faisant un mélange entre les deux, au lieu d'obtenir une conclusion partielle, ils obtiennent une conclusion invalide.

Après dans le détail, je viens juste de l'évoquer, pour les quelques langages que je connais, je saute au plafond. En C++ outre les boucles dans un ordre étrange, c'est du code vectorisable, il y a des libs pour ça. Dans un des code, j'ai eu l'horreur de voir une definition d'un template Matrix à la main. Moi aussi quand j'étais jeune j'ai codé intégralement sans rien y connaître mes libs de calcul matriciel (j'ai même écrit une lib d'algèbre linéaire en PHP, oui j'ai honte), oh ben on a des opérations inefficace aussi bien en temps qu'en mémoire, c'est étrange.

Au niveau du choix des langages, on a également de qui être dubitatif, Mathematica, vraiment. Oui un logiciel de calcul symbolique n'est pas un logiciel de calcul numérique. MATLAB, c'est efficace pour du calcul matriciel, oui les trois premières lettres du noms ne sont pas là par hasard. On peut être dubitatif également sur le soin apporté à chaque logiciel, par exemple en MATLAB on fait un MEX, en R on pourrait implémenter une procédure C ou C++ (qui aurait les perfs du C, et avec les libs adaptés genre Rcpp ça a le niveau de simplicité du R), et après la conclusion sur R est négative, on s'y attendait.

Après pour les conclusions, elles ne sont pas vraiment fausse (enfin certaines me laissent séptique pour ne pas dire ahuri), mais elles enfoncent des portes ouvertes. Oui les langages compilés sont plus rapide pour faire des boucles, oui les langages adaptés pour le calcul matriciel (R, MATLAB) ne sont pas adaptés pour faire des boucles, oui les langages de calculs symbolique ne sont pas adaptés pour faire du calcul numérique, oui la compilation JIT c'est le bien.

Bref, ça vaut rien ce benchmark. L'article ne semble pas publié dans une revue, autrement il aurait clairement mérité une réponse en règle.

Oui mais le don que le locataire a effectué avant est necessaire à l'obtention du rabais. Au yeux du fisc, et il a raison, cette partie fait intégralement partie du loyer, même si tu ne la touche pas, elle doit être intégré au calcul de ton revenu.

Et au niveau de la libre fixation du prix du loyer, c'est vrai si ni le locataire ni le propriétaire ne tire pas de bénéfices extérieur de la fixation des prix, ce qui n'est pas le cas en l'espèce. Sinon au yeux du fisc c'est un transfert d'argent (par exemple les parents qui louent à leurs enfant un logement à un prix très inférieur au marché, et bien ça doit être déclaré en tant que don).

Une rapide recherche sur le net montre que c'est connu.

Pour le meurtre en effet, tu n'as pas de graduation en fonction du moyen. Mais en fonction du moyen tu peux viser plus d'infractions et faire des combinaisons gagnantes. Par exemple pour ton meurtre à la petite cuillère, je pense que nous sommes dans la catégorie des actes de barbarie (222-1), qui entraînent un mort volontaire (221-1), et comme tu as fait un crime avant le meurtre (222-2) tu passe de 30 ans de réclusion criminelle à la réclusion criminelle à perpétuité.

Aussi le moyen peut te faire changer de catégorie. Dans le cas de ton suppositoire explosif, il sera difficile pour toi de plaider la non prémiditation. Ainsi tu rentres dans la catégorie des assassinats (221-3), ce qui change aussi la peine pour la réclusion criminelle à perpétuité.

Un conseil, au niveau moyen, reste simple !

Cher ami,

Ca m'étonnerais

Moi aussi vois-tu. Mais il en est ainsi des formules de politesse. De même que quand tu clôtures lettre adressé au service des impôts par « je vous prie, Madame, Monsieur, bla bla bla les plus sincères », tu n'en pense pas un mot, mais tu l'écris. Tu préfereras donc cette version je pense :

Cher contradicteur,

Cette hypothèse est juste fausse, pleine de préjugé et stupide.

Soit. C'est ton avis, qui ne semble pas partager par tous les intervenants de la discussion.

Le chiffrement, ca existe.

Oui. Mais pour que le mot de passe puisse t'être envoyé, il faut que la clef de déchiffrement soit accessible par le système automatisé. Nous nous plaçons, depuis le début, dans l'hypothèse d'une compromission du système de traitement automatisé, sinon le fait de discuter du mode de stockage n'aurait point d'intérêt. Dans ce cas, si la base est compromise, la clef de déchiffrement est également compromise, et donc au niveau sécurité, je le répète, c'est équivalent à un stockage en clair.

Sans rancune, je te laisse à ton thread d'expert de comptoir.

Peux-tu nous donner des références en matière de sécurité ? Que je sache à qui ne jamais faire confiance.

Cher ami,

Tu as du lire la discussion en diagonale, je te pardonne. L'hypothèse de départ était quelque chose comme « si un site est capable de renvoyer son mot de passe à un utilisateur, alors il est stocké en clair ». Là tu distingues le stockage via une bijection dont la réciproque est aisément calculable et le stockage en claire.

Je confirme, distinguer ces deux formes de stockage, c'est de la nuisance au minimum. Les arguments que tu m'invoques, c'est-à-dire possibilité de calculer la réciproque en un temps raisonnable ne sont pas adéquats. Nous sommes dans l’hypothèse d'un site qui renvoie à l'utilisateur son mot de passe.

Crois-tu sérieusement qu'un site qui te renvoie ton mot de passe l'avait hashé et l'a brutforcé rien que pour le le renvoyer ? Moi je n'y crois pas une seconde.

Relis bien le thread auquel tu réponds, et tu comprendras que tu fais preuve de nuisance, à dessein ou non, ça je ne le sais.

Ridicule, j'espère que tu ne code que des applis en php.

Ce que je code est bien plus interessant que des applis.