jben a écrit 847 commentaires

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.

Si la bijection réciproque est facile à calculer (du genre ce n'est pas un chiffrement avec une clef non disponible), c'est strictement équivalement à un stockage en clair.

Différencier le stockage via une fonction bijective dont la réciproque est connu et le stockage en clair stricto sensu, c'est caractéristique soit d'une incompétence flagrante soit d'une volonté de nuire. Je te laisse choisir.

si il y a un salt, là ça devient très dur.

Tu plaisantes j'espère ?

Je récupère le sel, qui est pas utilisateur en même temps que la base. Pour chaque utilisateur, je bruteforce connaissant le sel, chez moi, avec mon vieux processeur je fais 10⁵ hash/seconde, bref en espérance 5 secondes pour avoir le mot de passe d'un utilisateur.

Alors c'est vrai que qu'on ne peux pas travailler de manière globale, et qu'on doit travailler utilisateur par utilisateur, mais ça me parait un peu faiblard de baser la sécurité là dessus.

Ça me fait penser aux incompétents qui anonymisent une base de donnée de faisant un hash(nom.prenom) en fournissant à coté la liste des (nom,prenom)s.

Pourquoi réinventer la roue à chaque fois ? On a un standard pour faire cela, reconnu et tout et tout, ça se nomme HMAC et ça s'utilise avec un algo de calcul de condensat (MD5, SHA-1, SHA-2, SHA-3…). J'en parle dans un commentaire sur un des nombreux journaux sur le sujet. Moi je le fais en python, vous le faites en javascript, soit, on se fout de l'implémentation. Mais c'est pas une raison pour ne pas utiliser HMAC au lieu d'un algo maison.

Commentaire sur le reste du journal : à chaque fois on utilise les mêmes arguments, à chaque fois on voit les mêmes propositions, à chaque fois avec les mêmes défauts, et à chaque fois les même réponses. Ce genre de débat est aussi inintéressant qu'un débat sur la moto.

J'ai voulu tenter de mettre cela (que j'encode ici en base64) ça ne passe pas

8J2TnvCdk7Eg8J2Tu/Cdk6rwnZOw8J2Triwg8J2TuPCdk7Eg8J2TrfCdk67wnZO88J2TrvCdk7zw
nZO58J2TuPCdk77wnZO7LCDwnZOe8J2TsSDwnZO/8J2TsvCdk67wnZO18J2TtfCdk67wnZO88J2T
vPCdk64g8J2TrvCdk7fwnZO38J2TrvCdk7bwnZOy8J2Triwg8J2TtyfwnZOq8J2Tsi3wnZOz8J2T
riDwnZOt8J2TuPCdk7fwnZOsIPCdk73wnZOq8J2Tt/Cdk70g8J2Tv/Cdk67wnZOs8J2TviDwnZO6
8J2TvvCdk64g8J2TufCdk7jwnZO+8J2TuyDwnZOs8J2TrvCdk73wnZO98J2TriDwnZOy8J2Tt/Cd
k6/wnZOq8J2TtvCdk7LwnZOuID8K

Encore un système qui ne supporte pas les unicodes plus haut que U+10000. Je ne sais pas pourquoi, mais c'est assez fréquent.

Tu remarqueras que la tranche horaire à laquelle je poste des messages avec accents est toujours différente de celle à laquelle je poste des messages avec accents. Tu remarqueras aussi que j'ai souvent tendance à poster en fin de journée, voire en pleine nuit. Tu pourras alors inférer que je me trouve sur un autre continent, et que je n'ai pas accès à du bépo partout où je suis.

Non mais cette excuse pourrie, à un moment ça suffit. Ça fait plusieurs années que j'utilise un qwerty-us en France ou ailleurs (actuellement ailleurs), et je ne vous pas en quoi ça pose un problème.

Tu peux avoir plein de raison de ne pas mettre les accents, allant de la mauvaise foi à la flemme en passant pas l'ignorance orthographique (ce qui est mon cas), mais le choix du clavier ne fait définitivement pas partie de ces raisons. Te viendrais-t'il à l'idée de poster sur un forum russe/chinois/whatever en utilisant que l'ASCII avec comme excuse « nan mais je ne sais pas faire autre chose avec mon clavier ».

En fait à la relecture de ton commentaire (le temps d'édition est trop court) j'ai pensé à autre chose. Ça dépend quelle est ta constante. Si (comme moi) tu as une certaine distance à faire qui est fixé, alors afficher en L/km est judicieux, tu minimise le pognon mis pour une distance. Si tu as une certaine quantité de carburant à mettre et après tu marches à pied, alors afficher en km/L est judicieux, tu maximise la distance pour un pognon fixé.

C'est ce que je disais dans mon premier messages, les deux ont leurs avantages, même si perso je préfère l'un à l'autre. Mais il n'y a pas une grandeur qui est tout bien et l'autre tout mal.

Si tu passe de .065 à .069 L/km, alors tu passes de 500 à 470 km. Je pense que le ressenti est le même dans les deux cas. Ton raisonnement était fallacieux.

Après tu dis que ce que tu vois c'est la distance, oui, mais c'est aussi ce que tu ne maîtrise pas. Souvent tu cherche à diminuer la quantité d'essence pour un même trajet. Et de plus présenté comme ça, c'est directement lié au pognon que tu dépenses pour faire avancer ta boîte de métal (j'ai aussi une voiture, ce n'est pas un raisonnement anti-voiture, mais il faut avouer que ça reste une boîte de métal) ou à la quantité de polluants que tu rejette. Bref ce sachant que tu dois faire une certaine distance qui t'est imposée, cette consommation en L/km est proportionnellement lié à ton pogon ou à ta conscience écologique suivant ton obédience.

Mais donc: je ne l'ai pas touché, pas de témoin à part mes passagers (apparemment ça ne compte pas pour les assureurs) et donc 100% pour ma gueule.

Quand ton assureur te propose une solution que tu ne trouve pas acceptable, il n'y a que trois raisons de le laisser faire, et de ne pas porter l'affaire au civil contre l'autre automobiliste ou ton assureur suivant le cas (souvent tu attaques l'autre automobilistes et les assureurs vont se joindre au dossier) :

• Considérer que les assureurs sont des dieux qui ont raison.
• Ne pas vouloir s'emmerder pour cela.
• Avoir tort.

Après le problème, c'est que pour l'avoir déjà fait, c'est que les assureurs ne sont pas effrayés par un imbécile se mettant à déclamer « je vais aller en justice », il faut vraiment le faire. Ce n'est que quelques jours avant l'audience (une heure avant dans mon cas) que comme par miracle, les assureurs réussissent à se mettre d'accord sur une solution que tu trouve acceptable.

En fait elles sont toutes les deux pertinentes dans certains cas.

Par exemple, je fais 10 km avec une conduite souple .05 L/km (20 km/L), et 10 km avec une conduite agressive, .1 L/km (10 km/L), ma consommation moyenne sera de .075 L/km (13.3 km/L) et non .067 L/km (15 km/L). On peut faire la moyenne des L/km mais pas des km/L.

Par contre si tu dit, « j'utilise la moitié de mon plein pour me faire plaisir en conduisant comme une brute (se faire plaisir dans ou sur un engin motorisé, c'est étrange) et l'autre moitié en conduite éco », alors dans ce cas, il faudra faire la moyenne des km/L et non des L/km.

Après je pense que intuitivement, on fait plus de somme et moyenne de quantité qui correspondent à des L/km et donc que l’unité européenne est plus adaptés. Je pense que l'utilisation d'une distance par volume de carburant nous conduit à faire des moyenne non appropriées, et à sous-estimer notre consommation réelle.

Avec une phrase par ligne c'est assez rare d'avoir 2000 caractères, sauf quand j'écris aux impôts.

Après c'est aussi trompeur le numéro de ligne, des fois il fait référence à la dernière ligne du paragraphe…

Édit: j'ai cru que tu avais répondu à l'commentaires que je viens de poster dans ce thread.

Le fait que le retour à la ligne (simple) ne soit pas significatif permet aussi des trucs sympa. J'essai par exemple lorque je rédige un document MarkDown ou LaTeX qui est versionné, d'utiliser la logique une phrase, une ligne. Les lignes peuvent être longues ce n'est pas le problème, je ne respecte pas de limite de nombre de caractères pas ligne. En tout cas, ça permet au gestionnaire de version d'être plus efficace, et d'avoir moins de conflits.

Mais pour cela, il faut que le retour à la ligne (simple, toujours) ne soit pas significatif.

Sans vouloir le défendre, quand j'écris un commentaire sur linuxfr, je mets des retours à la ligne un peu n'importe où, avec l'habitude que les retours à la ligne (non dupliqués) ne sont pas significatifs en MarkDown. Ce n'est qu'après avoir écrit mon commentaire que je suis obligé de le relire pour les supprimer, et ça me les brise sérieusement. J'ai proposé un rapport de bug pour proposer de rendre ce comportement optionnel resté sans effet à ce jour.

Ceci n'est en aucun cas une critique, j'essaie juste d'avoir une explication rationnelle à certains retours à la ligne intempestifs que l'on constate.

Le module cifs est-il chargé lors du montage des filesystems au boot ? Si il n'est chargé qu'après, ça expliquerai pourquoi le mount -a fonctionne et qu'il ne fait pas au boot. Tu as regardé les logs de démarrage ?