Renault a écrit 7161 commentaires

Je pense qu'on peut regretter le fait historique que Linux, en tant que projet communautaire de noyau libre, est parti sur un noyau monolithique plutôt qu'un micro-noyau—aujourd'hui le noyau est presque impossible à sécuriser (je parle de sortir du jeu du chat et de la souris des attaques/réponses en rendant toute les classes d'attaques courantes impossibles grâce à la conception du système)

Deux choses. Encore une fois, tu oublies significativement le contexte ou tu le rends négligeable. Pourtant ils sont fondamentaux.

Linux était un projet jouet pour Torvalds, pour apprendre l'x86. Le monolithique était juste le moyen le plus simple pour aboutir à un résultat rapidement. Ce sont ensuite les autres qui ont porté Linux au delà du projet jouet, car Linux était à ce moment là, le seul noyau libre convenable. *BSD avait l'épée de Damoclès du procès (et est de toute façon monolithique aussi), Minix n'était pas libre et Hurd on l'attend toujours.

Torvalds n'aurait jamais lancé un tel projet si un micro-noyau libre existait et fonctionnait, Linux n'aurait jamais été un micro-noyau car ce n'était pas l'objectif de Torvalds avec le contexte de l'époque.

Et l'avenir lui a donné raison, il n'existe aucun micro-noyau pur avec une utilisation très large. Windows et macOS (qui ne sont pas codés par des ignorants non plus) n'ont jamais franchi le pas de tout mettre en espace utilisateur faute de performances acceptables.

Et on peut largement sécuriser encore le noyau Linux sans aller dans le micro-noyau fondamentalement. Mais là encore, la sécurité absolue au niveau noyau, c'est contre les performances aussi. Il faut faire des compromis. Et le compromis, ce n'est pas un micro-noyau pur.

Mais il y a une différence importante, c'est que (1) à l'époque les micronoyaux étaient difficiles à rendre efficace (L4 a fait beaucoup de progrès depuis), et (2) tu parles d'un choix de design fondamental qui demande de complètement tout refaire.

Tu as pourtant reproché des choses à Go qui demanderaient de changer l'architecture de Go. et qui est difficile à faire aujourd'hui car ce n'est pas cohérent avec l'architecture choisie. Que c'est trop tard.

Il ne s'agit pas de demander de tout changer au langage, ou de le transformer en une variante de Coq. C'est une fonctionnalité qui n'est pas copmliquée à expliquer ou implémenter, qui se mélange bien avec la plupart des autres traits du langage, et qui lui donne une meilleure capacité à modéliser les domaines métiers—et donc d'écrire du code plus clair. On n'est pas du tout au niveau du "il faut tout refaire avec un micro-noyau".

Mais pourtant on te l'a expliqué que les développeurs de Go, sur cet aspect, connaissait ce que tu énonçais mais l'ont ignoré pour certaines raisons. Tu peux dire ce que tu veux, mais ils ont fait un choix, un compromis et c'est nécessaire d'en faire sur certains sujets. Honnêtement, je ne suis toujours pas convaincu que c'est un manque aussi important que tu l'énonces.

Tu parles de récrire des millions de lignes de code, mais au moment où Go a été conçu, il n'y avait aucune ligne déjà écrite dans ce langage (ou alors juste des exemples exploratoires).

Tu oublies le code passé et la formation des gens. Il y a bien plus de gens, surtout dans le milieu où Go évolue, où le C (voire C++ et Python) est la référence qu'OCaml ou Rust. Go était destiné quand même à ces gens là, une évolution en douceur. Cela ne me paraît pas débile de garder un langage simple et assez proche d'un autre langage pour attirer les développeurs sans leur faire peur.

De la même façon que développeurs COBOL n'est pas parti sur OCaml non plus pour refaire les systèmes bancaires alors que les avantages du langage sont évidents. Mais voilà, pareil, les gens efficaces en Java tu en as suffisamment et les développeurs de COBOL trouvent sans doute la transition plus douce aussi.

C'est un ensemble de choix fait par des gens, et l'un des choix qui se propose c'est de réfléchir à l'apport de la théorie, d'écouter ce qu'elle a à dire et d'entrer en contact avec des gens qui en font

Tu es toujours dans l'histoire du théorie -> pratique, mais au vue de tes déclarations où tu sembles (volontairement ou non) ignorer ce qu'est la vraie vie d'un projet informatique en entreprise, du savoir des développeurs. Je dirais que l'inverse devrait aussi se faire, que les théoriciens ne s'offusquent pas car ils n'ont pas été entendus par eux. Peut être qu'ils l'ont été mais qu'ils ont arbitré différemment avec leur justification (ce que Go notamment a explicité sur certains choix). Je trouve facile de toujours réclamer à être entendu mais de ne pas faire l'effort soi même dans l'autre sens.

Sauf que heureusement, l'ABI du noyau avec l'espace utilisateur est très stable. Cela peut tenir des années ainsi.

L'exemple microkernel vs monolytique n'est pas une bonne analogie. A ma connaissance, l'état de l'art sur les systèmes a micronoyaux n'a pas encore depassé celui des architectures monolithiques mis a part dans certains domaines très précis mais pas de manière générale.

Pourtant au niveau de la recherche sur le sujet, le noyau monolithique est obsolète par conception. Ce n'est pas moi qui le dit mais Tanambaum en 1992, qui est quand même un chercheur émérite du domaine. D'autant plus qu'il parlait au nom de son milieu, et non uniquement son point de vue personnel. Et il a répété jusqu'à sa retraite de la recherche que la conception de Linux, en n'étant pas un noyau monolithique, était toujours une erreur, que seuls les pure micro-noyaux avaient grâce à ses yeux.

Il a comparé Linux, en 1992 quand Torvalds était encore qu'un étudiant, qu'il ne lui donnerait même pas la moyenne pour ce projet à cause de ce choix architectural dépassé.

Bref, c'est en tout point semblable à ce que gasche déclare à propos de Go en tant que faute professionnelle en ignorant la recherche de son secteur d'activité sur le sujet.

Opposer théorie et pratique n'a pas de sens.

Bah, si.
Les deux doivent communiquer pour que le tout avance, mais on ne peut pas prétendre qu'une bonne idée théorique est systématiquement une bonne idée pratique. Nous en avons constamment la preuve, les noyaux (domaine que je connais mieux que les langages) en est une bonne démonstration car le modèle actuel dominant est plus sur les approches hybrides (monolithique modulaire pour Linux et *BSD ou noyau hybride comme ceux de macOS ou Windows) que pure micro-noyau qui sont réservés aujourd'hui à des niches.

En général la théorie cherche la solution la plus élégante. Sur le papier, la théorie peut toujours l'emporter sur l'approche pratique. Mais voilà, la pratique c'est aussi les contraintes de la vie : la formation, les outils, les projets existants, l'Histoire. La théorie ne s'en préoccupe pas vraiment et c'est normal. Mais la pratique ne peut faire comme la théorie et tout refaire de zéro car la théorie dit que c'est mieux ainsi.

Certes ces nouveaux outils impliquent un cout non négligeable de formation, mais a choisir en entre cout de formation et cout en QA ou debugging, le choix sera vite fait. Payer des journées de dev pour coder ce qui pourrait se faire automatiquement avec des langages modernes ou a débugger des data race alors que le compilo pourrait en garantir l'absence a chaque build sera une position de plus en plus dur a justifier.

Mais tu ne peux dire demain de jeter des millions de lignes de code, de former des millions de développeurs d'un coup sur les nouvelles pratiques et espérer que ce soit économiquement intéressant. Les processus d'évolution que tu cites demandent du temps. Beaucoup de temps. Même certains langages comme COBOL, pourtant décriés, avec peu de personnes capables d'en tirer quelque chose était jusqu'à peu le pilier des applications bancaires. La transition vers Java fut très longue. Tu ne crois quand même pas qu'ils vont passer à Rust ou autre dès demain, si ?

Sinon dès demain tout le monde utiliserait Coq pour avoir un programme sans bogue. Mais ce n'est pas le cas, car le gain n'en mérite peut être pas le coût associé. Ce n'est pas pour rien que Coq est globalement employé par les secteurs où le niveau de criticité est telle que Coq revient finalement moins cher qu'un code C minimal testé de toute part. Car c'est là qu'il se met en valeur.

Tu t'inventes ta propre histoire de Go.

Pas vraiment. Cette page ne contre indique pas ce que j'énonce.
En 2007, nombre des domaines qu'ils listent sont trustés par le C, pour des raisons souvent historiques mais aussi parce qu'il est fortement lié à UNIX ce qui le rendait très apprécié pour la programmation système. Et le C a influé grandement le C++, Java et Python même si peu à peu, certains s'en éloignent aujourd'hui.

Bref, ils ne le citent pas directement dans cet article, mais ça reste une caractéristique importante de Go. Le fait que Pike et Thompson, qui ont fait du C (ou du Limbo, que tu parlais précédemment) pratiquement toute leur vie, ont contribué à Go dès les débuts n'est pas je pense étranger à cela.

L'Histoire ne se résume pas à une FAQ d'un site Web (qui peut aussi subir des effets du genre storytelling pour mieux promouvoir le produit maison), c'est aussi un contexte historique, des personnages avec une expérience, un passé…

Les types sommes ont été introduits par le langage Hope (dynamiquement typé) dans les années 70. Ils sont utilisés à moyenne échelle par les programmeurs ML et Haskell depuis les années 90. (Tous les étudiants qui ont fait l'option informatique une prépa MPSI dans les 20 dernières années en France les ont appris; une partie de ces étudiants travaillent d'ailleurs maintenant à Google.) Ce n'est pas exactement ce qu'on appelle "l'état de l'art".

Mais est-ce un vrai manque ? Les lambda-calculs, ce n'est pas nouveau non plus, beaucoup de langages n'en ont pas. Est-ce grave ? Est-ce que ce que tu énonces était essentiel pour répondre à leur problématique ? J'ai l'impression que non.

Tu as une vision très théorique de la situation. D'autres plus empiriques, ils ne prennent que ce qui est nécessaire ou conforme à ce qui est voulu. Tu disais que les concepteurs de langages devaient écouter les théoriciens, je n'ai rien contre cela, mais l'inverse est vrai aussi, les chercheurs doivent écouter et comprendre ceux qui programment dans l'ensemble des contextes industriels existants.

Il me semble que c'est courant pour nous tous, quand on écrit du code, de dire (ou d'écrire) familièrement : ça c'est laid. (Ça ne t'arrive jamais ? C'est forcément, pour toi, un signe de mépris intolérable pour la personne qui a écrit le code, souvent soi-même ?)

Il y a une histoire de contexte. Dire c'est laid pour rire, pourquoi pas, je le fais aussi, mais comme tu insistais pour dire que le Go c'est de la merde, le côté humoristique a disparu.

Le plus amusant, c'est qu'on avait eu un débat ici il y a quoi, 2 ans sur ce qui était acceptable en terme de communication, qu'il fallait éviter de froisser les gens. Tu semblais soutenir que c'était possible de parler entre adultes systématiquement sans jamais froisser quiconque tout en pouvant développer une culture communautaire saine. Alors, tu soutiens toujours le même point de vue ?

Au contraire j'ai dit "à l'époque de C c'était compréhensible, aujourd'hui (à l'époque de Go) c'est une faute professionnelle". Je parle de faute dans le contexte de Go. Oui, je pense qu'on peut argumenter qu'ignorer une fonctionnalité de langages de programmation (les types somme) qui ajoute peu de complexité, améliore la clarté et la sûreté et évite des bugs et des erreurs, quand on est, professionnellement, concepteur de langage de programmation, c'est une faute.

Bah non, je conteste encore, ce serait comme dire que pondre un noyau monolithique serait aussi une faute professionnelle.

Le Go a une cible très précise en tête, qui est en gros de remplacer le C tout en étant proche de lui pour la programmation système (qui est un domaine particulier, rarement considéré par la recherche informatique qui semble se concentrer sur des applications plus lourdes / critiques).

Le Go doit donc avoir cette simplicité (de conception) du C, reprendre l'essentiel de sa syntaxe (un développeur C n'est pas choqué par la syntaxe du Go) tout en apportant la possibilité de faire des trucs utiles simplement (comme la programmation parallèle). Le cahier des charges est rempli, il fait son boulot.

Le fait qu'il ne soit pas à l'état de l'art du domaine n'est pas le sujet. En réalité, tout le monde s'en moque de suivre l'état de l'art, ce n'est pas le critère. La question est toujours "est-ce que l'état de l'art m'apporte quelque chose pour répondre à mon cahier des charges ?" Parfois oui, parfois non, j'ai l'impression que pour le Go (de ce que j'en ai lu), c'est plutôt voulu et assumé de faire autrement, car l'état de l'art ne l'aidait pas pour ce qu'ils voulaient faire.

Dire que les gens commettent des fautes, je ne trouve pas que ce soit méprisant.

Attends, je te cite, par exemple :

j'ai tendance à préfèrer augmenter la quantité de beauté dans le monde qu'atténuer les souffrances des gens qui vivent dans le laid,

Tu ne trouves pas que de traiter tout ce qui ne répond pas à tes critères comme du laid ne soit pas méprisant ? Envers ceux qui ont développé et qui utilisent ce langage pour diverses raisons.

J'ai aussi appuyé le commentaire de c3 sur le fait que Go ignore (volontairement) les développements en langages de programmation qui ne viennent pas de ses auteurs. Je ne pense pas que rappeler un fait soit un signe de "condescendance assez violente", même quand il n'est pas à l'avantage du langage dont on parle.

Bah si, car tu sembles prioriser dans les critères le fait que les concepteurs doivent écouter et suivre les chercheurs systématiquement. Tu fais un jugement de valeur et cela se transcrit tout le long de ta prose ce qui ressemble à une grosse condescendance envers ceux qui n'ont pas les mêmes critères, objectifs que toi et qui du coup ne suivent pas forcément la même voie.

Si tu respectais ces choix, tu n'en ferais pas des pavés pour dire qu'ils sont dans l'erreur et que tu es dans le vrai. Tu le mentionnerais rapidement et tu passerais à autre chose.

Personnellement, je trouve que l'ensemble de ton discours sur C et Go montre une certaine forme de condescendance assez violente de ta part (voire de ton milieu) envers ces langages.

Non pas que ces langages ne présentent pas de défauts, loin de là, mais tu sembles tellement obnubilé sur l'aspect théorique que tu perds toute vision des autres critères pourtant essentiels dans le milieu. Un peu comme certains mathématiciens qui hurlent devant des documents de physiques sur des points qui n'ont finalement pas d'impacts sur la valeur du document et qui sert plus de prétexte à critiquer qu'à vraiment faire avancer le sujet.

C'est compréhensible pour C qui a été écrit par des chercheurs en systèmes à une époque où il y avait peu de communication entre les équipes de recherche (il faut quand même noter que C et ML ont été inventé à la même époque, donc l'idée des types algébriques était déjà dans l'air et aurait pu être ajoutée à C si ses concepteurs avaient été un peu curieux), aujourd'hui c'est une faute professionnelle, appelons un chat un chat.

Appeler le C de faute professionnelle, c'est un peu fort quand même. Dans ce cas je dirais que tout le monde devrait être au chômage.

Non pas que le C est parfait, je connais ses défauts, mais je connais aussi ses avantages (avantages essentiels pour l'époque) : tu aurais pu écrire UNIX en 1970 avec ML ou un langage similaire, dans les conditions qu'il a été écrit, pour les machines cibles ? J'en doute très certainement.

Tu sembles aussi induire que Ritchie et Thompson sont de sombres incompétents, étant donné leurs parcours, leurs apports et le milieu dans lequel ils ont évolué, j'émets un doute sur cet avis. Apparemment, comme d'autres, ils ont choisi une voie moins élégante théoriquement mais qui permettait de résoudre des problèmes concrets de leur époque.

Cela me fait penser un peu au discours Tanambaum contre Torvalds sur le noyau monolithique contre micro-noyau. Théoriquement le micro-noyau explose tout, mais voilà il y a les contraintes de la vraie vie aussi et 25 ans après on attend toujours le micro-noyau qui montrera que c'était la seule voie à suivre. Ni Apple, ni Microsoft n'ont trouvé le 100% noyau assez séduisant pour l'utiliser massivement, préférant une approche hybride. Et Minix, malgré sa licence libre, peine à convaincre face à Linux dans la plupart des domaines.

Bref, je pense que tu devrais un peu plus t'informer sur les circonstances du choix de conception de certains produits, de constater que la méthode élégante n'était pas à ce moment là pertinente. Ce n'est pas parce que des gens ont choisi une autre voie qu'ils sont incompétents, cela peut être une explication, mais il y en a d'autres.

Oui et non, je pense que nous sommes ici intéressés par des sites VO en anglais, par contre une VO en chinois ou russe serait probablement moins bien qu'une traduction anglaise ou française (suivant les gens bien entendus).

je croyais que le code libre est trop bien audité parce que libre.

Le libre c'est bien car tu peux l'auditer toi même, ou payer quelqu'un pour le faire. Mais ce n'est pas magique, ce n'est pas parce que c'est libre que tout le monde relis le code.

Avec le proprio tu es obligé de faire confiance à l'éditeur sur le sujet, à moins d'être un gros client ou un gouvernement (qui peuvent se permettre en général de regarder le code source d'un code proprio).

T'es pas obligé de tout faire planter. Tu peux aussi informer tes utilisateurs et les inciter à désactiver le wifi en attendant.

Sachant que pour certains (et même beaucoup de gens), le Wifi est le seul moyen d'accéder à Internet, ce n'est pas réaliste.

Après chacun est responsable de faire le choix entre "envoyer du traffic à peine aussi sécurisé que si ça passait en clair" via le wifi ou se passer du wifi dans l'intervalle de la sortie du patch officiel.

Le trafic de ce que j'ai compris n'est pas envoyé en clair, même si un pirate y a accès, il ne peut pas outrepasser les solutions type HTTPS. Sachant que le HTTPS et autres protocoles de sécurité sont de plus en plus employés, cela reste moins grave que ce genre d'attaques par le passé.

De plus, si la faille existe, aucune trace de son utilisation a été constatée, et dévoiler le correctif directement aurait porté à la connaissance de tous les vilains de comment procéder pour l'exploiter. Je ne sais pas ce qui est le mieux, mais tout dévoiler le plus vite possible n'est pas forcément la meilleure solution.

Une boite qui n'est pas capable de fournir et pousser un patch dans un délai d'un mois sur une faille aussi critique va de toute façon demander des délais à l'infini.

Quand tu es une entreprise, type Microsoft, Samsung ou Apple, avec des milliards d'utilisateurs dans le monde, plusieurs déclinaisons de logiciels / matériels à tester alors que tes utilisateurs payent chers pour avoir un produit qui marche, 1 mois ce n'est pas très long pour faire le travail nécessaire et garantir la qualité du correctif (en plus d'identifier le problème et le corriger). Car bon, si c'est pour envoyer à l'arrache un correctif qui fait planter le téléphone ou l'ordinateur d'un utilisateur sur X, ce n'est pas très professionnel. Et cela peut arriver.

Car admettons, si le correctif d'OpenBSD ne fonctionne pas partout, je pense que Theo va envoyer un gros RTFM à ces utilisateurs pour corriger cela à la main, ou rapporter les bogues car c'est lié éventuellement au matériel ou à une configuration spécifique du logiciel. Mais pour l'utilisateur lambda de certaines entreprises, ce n'est pas envisageable. Ce travail doit être fait avant.

Je ne sais pas pour toi Nal, mais après toutes ces années, je n'ai toujours pas la certitude que mon code C sera garanti sans failles de sécurité.

Ne t'inquiète pas, avec Rust tu n'as pas cette certitude non plus.
Si Rust vérifie un certain nombre de choses à la compilation pour éviter les buffer overflow et autres soucis du style qui peuvent entraîner des soucis de sécurité, tous les problèmes de sécurité ne viennent pas uniquement de ce genre d'erreurs.

Tes applications en Rust peuvent donc avoir des failles, même si théoriquement tu devrais éviter beaucoup de failles courants.

Personnellement je trouve ça plutôt bien qu'on s'indigne des soldats morts et pas qu'on s'en foute en disant "seulement un?!".

Disons que, c'est bien de se soucier de ses soldats et de leur famille. Mais certains semblent remettre en cause d'une opération militaire dès qu'un militaire français est mort au combat.

On sait très bien que la guerre est dangereuse, risquée, quelque soit le conflit. Si on souhaite éviter des décès, la meilleure solution est de ne pas envoyer de soldats dès le départ. Remettre en cause un conflit car un soldat en est mort, ça n'a pas de sens.

Le bus n'a pas toujours une voie dédiée ou ne peut pas emprunter certaines routes, faute de place pour manœuvrer. Du coup il est aussi sensible à la circulation (donc pas très fiable en heure de pointe).

Et je ne sais pas si tu as constaté, mais ce qui fait qu'à Paris la voiture est évitable c'est aussi la diversité des moyens de transports. Cela permet notamment d'accepter plus de voyageurs car tu ne peux pas avoir une cadence infinie pour accepter tout le monde dans le métro (ou tout le monde dans le bus). Il n'est pas rare que les bus ou métros (pour Marseille) soient bondés dans les villes que j'ai cité.

(et il semble de ce côté qu'ils pourraient voir pas mal de choses, mais j'ai un peu de mal à faire la part des choses entre le réel et le fantasme lorsque les détracteurs de Linky s'expriment).

Techniquement Linky peut en effet permettre de savoir pas mal de choses à partir des données qu'il collecte. Mais cela est fait en local.

Mais justement, la CNIL a exigé des garanties sur la fréquence d’émission et les données collectées pour éviter qu'Enedis ou ton fournisseur puissent en savoir trop, et que l'utilisateur peut s'opposer à un certain nombre de choses (transmissions des données à un tiers, au savegarde local des données précises sur sa consommation).

https://www.cnil.fr/fr/compteurs-communicants-linky-la-position-de-la-cnil-sur-le-stockage-local-de-la-courbe-de-charge-0

Bref, je trouve que la CNIL apporte assez de garanties de ce côté là.

Je pense aussi que la voiture autonome sera partagée, gérée par Uber et co, mais il restera des voitures individuelles, qui deviendront de plus en plus un luxe.

Sans doute, personnellement si > 90% des voitures sont partagées (ce qui me semble réaliste), le concept de voiture individuelle généralisée sera morte.

Par contre, la sécurité me fait peur: en gros il va falloir des caméras braquées vers les passagers pour confirmer qui salope ou dégrade la voiture.

Non, on peut imaginer des caméras rotatives ou avec un cache, permettant de ne prendre le cliché physiquement que quand la course est finie, pour constater l'état final du véhicule. Ou que cela se fasse sur signalement du passager suivant.

Il est évident qu'il faut une législation qui impose ce genre de chose pour garantir la vie privée des passagers un minimum.

Moi j'adore tout le mal que tu te donnes pour cacher la zone géographique que tu critiques. Tu as peur que le maire porte plainte pour diffamation ? Ou peut être qu'on te démontre que les décisions prises ne sont pas irrationnelles ?

Je ne dis pas que cela n'entre pas dans le calcul, je suis sceptique sur le fait que si tu supprimes cette taxe, la mobilité professionnelle décollerait. Ce n'est pas la même chose. Car si tu supprimes cette taxe et qu'en contre partie tu n'as qu'un pourcent de gens qui acceptent de bouger grâce à ça en plus, le coût risque d'être plus élevé que le gain.

Il faut donc motiver ce genre de décisions par des chiffres, des études qui mettent en évidence qu'une telle suppression aurait un effet non négligeable. Tu en as ? car c'est toi qui t'avance sur cet effet bénéfique.

En tout cas, les collègues que j'ai croisé et qui ont déménagé en tant que proprio, aucun n'a revendu pour racheter un logement dans la nouvelle ville. Tous sont redevenus locataires pour louer leur bien initial. Et la raison n'était pas la taxe, c'était bien la démarche de vendre / acheter dans des délais réduits qui était le principal frein.

Et preuve qu'on peut accepter une opportunité professionnelle sans revendre (et donc payer la dite taxe). Ce n'est pas sans inconvénients, mais la vente / achat n'est pas mieux sur bien des points en fait. Elle est d'ailleurs peu viable si tu es mobile (donc que tu souhaites bouger souvent).

Ce serait vrai si la ville gérait ses déchets en interne. Au vu des immenses tas de m*rde (pardon, de "déchets ultimes") qu'on vient enterrer chez nous, le bilan est nettement moins positif.

Pourtant les villes avec un transport en commun efficaces ont un bilan environnemental bien supérieur par habitant qu'à un campagnard lambda. Déchets inclus (d'ailleurs une partie sert à alimenter l'électricité ou le chauffage de la zone).

Idem sur le chauffage. L'habitat vertical permet de réduire la facture par personne, mais si vous acceptiez tous (y compris le mec du RDC, qui profite pas du chauffage des mecs d'en dessous) de vous chauffer aussi peu que le mec qui compte son bois/fioul, ça serait probablement encore plus efficace.

Tu oublies que les immeubles sont intéressants pour le chauffage pour deux autres raisons (dont bénéficie le gars au RDC) : moins de surface de contact avec l'extérieur (car pas de toit sauf pour le dernier étage, rarement 4 façades direct pour chaque appartement), donc moins de perdition, mais aussi volume à chauffer plus faible par habitant donc moins coûteux à chauffer.

Vos transports en commun sont hyper-vertueux quand ils sont pleins, par rapport à une voiture individuelle. Mais quid des rames qui circulent à vide "parce qu'en dehors des heures de pointe", mais que vous n'êtes quand même pas prêts à attendre une heure entre chaque métro?

Vu ce qu'un bus, tram ou rame plein permet d'économiser en une fois, il peut faire quelques passages à vide que cela reste positif environnementalement parlant. Le bilan citadin sur cet aspect est indéniable (d'autant qu'en général en heure creuse, il y a moins de véhicules qui tournent à vide que de véhicules pleins en heure de pointe).

Mais c'est évidemment un défaut du transport en commun et qui fait qu'il se cantonnera aux grands axes où le trafic est suffisant pour que ce soit intéressant économiquement. Pour les axes plus mineurs, voitures (autonomes sans doute un jour), à pied ou vélo.

Étant donné le gain écologique et économique que cela peut engendrer, je pense que cela se généralisera tôt ou tard. des flottes contrôlées par l'État ou les villes.

Ce que tu pointes est vrai, mais cela se contourne. Par exemple on peut imaginer qu'une photo de la voiture est prise quand le passager s'en va, ou que le suivant puisse signaler l'état déplorable de la voiture ce qui permettra de facturer le nettoyage au responsable.

Et on peut aussi constater que les gens font de plus en plus de covoiturage, ce qui était difficilement imaginable à cet ampleur il y a seulement quelques années car la voiture individuelle c'était la liberté. Mais comme la voiture devient de plus en plus une contrainte de temps et d'argent, probable que cela évolue vers ce genre de dispositif et que cela s'inscrit dans les mœurs.

Car, au moins, 3 villes sur les 10 plus peuplées de France (Marseille, Toulon et Nice) ont un relief important rendant les solutions parisiennes type métro / tramway pas utilisable sur toute la surface des villes et des périphéries. Cela freine évidemment l'usage du vélo localement. Déjà que pour cette zone c'est impossible de doubler les voies de trains (car actuellement c'est une voie par sens entre Marseille et Cannes), que pour Toulon il a fallut 30 ans de travaux pour seulement quelques kilomètres d'un tunnel souterrain pour traverser la ville sans boucher ses artères de surface. Je n'ose imaginer un réseau complet de métro.

Sans compter les villes au bord de la mer, dont celles citées plus haut, où le métro a donc des contraintes de circulation. De même pour le ferroviaire (type RER).

Puis bien sûr il faut financer tout cela (Paris et l'Île de France c'est très riche, très peuplé et avec un soutien énorme de l'État car il y a tout là bas), nul doute que certaines grandes villes pourraient rapidement rentabiliser ce genre de travaux. Mais de là à généraliser à toutes les villes, mêmes moyennes, j'en doute.

Puis bon, Paris c'est génial en terme de transport en commun. Quand je viens un week-end sur place, jamais besoin d'une voiture. Mais de ce que j'en comprends, ce raisonnement ne fonctionne que pour Paris et sa proche banlieue. Le reste de l'Île de France (où la population reste importante) dépend trop de la voiture.

C'est pour quoi je n'ai pas précisé toute la France d'une part, d'autre part je suis conscients de ce genre de soucis, mais je ne vois pas le rapport avec la taxe immobilière (avec ou sans, la situation est compliquée).

Si tu utilises le bouton login en haut des pages, normalement tu devrais pouvoir utiliser d'autres fournisseurs OpenID, le compte FAS n'est pas nécessaire normalement.

J'avoue qu'ayant déjà un compte FAS, je n'ai pas testé les autres possibilités.

Tu es bizarre. On parle d'enlever le principale frein qui est le cout délirant d'une telle opération et tu ne crois pas que cela enlève un frein à la réalisation d'une telle opération.

Croire que la taxe sur l'achat immobilier est la seule cause du coût de l'opération, c'est se fourvoyer. Croire que le prix est le seul frein est je pense aussi discutable. Il y a l'aspect temps, pour retrouver un nouveau logement, revendre le tien, le tout dans des délais rendant l'opération compatible.

Sans compter que, je le rappelle, comme tu n'as pas d'assurance que tu resteras 50 ans dans le nouveau logement, tu peux te retrouver à répéter l'opération régulièrement. Avec ou sans taxe, ce n'est pas forcément très gérable.

Quand tu achètes une maisons ce n'est pas sur un coup de tête, mais se faire virer ou avoir une bonne opportunité, cela se fait du jour au lendemain !

Mais est-ce que c'est vrai la taxe immobilière qui t'empêche de saisir l'opportunité ? J'en doute sincèrement.

On peut, mais encore faut-il trouver la source d'économie, faire accepter politiquement la solution auprès de la population, etc.

Toi même qui disait que le budget de la justice baissait constamment et manquait de ressources, n'est-ce pas contradictoire ? ;)

Peut être, peut être pas.
Une vente immobilière est un acte qui prend du temps, qui est compliqué et qui a un grand enjeu. Après tout, étant donné l'importance d'une maison et de son coût, tu prends du temps pour acheter ta maison, tu ne fais pas ça sur un coup de tête.

Acheter et revendre dans la foulée dans le cadre d'un déménagement est de fait compliqué (d'ailleurs certains préfèrent redevenir locataire et relouer leur bien pour cette raison). Il faut en plus s'assurer que tu achètes pas trop cher, que tu revends à un prix pas trop bas, le tout dans des délais courts.

Sans compter que peu de boîtes sont prêtes à attendre 6 mois l'arrivée du candidat.

Du coup est-ce que cette taxe est un réel frein à la mobilité ? Je n'en suis pas sûr. La complexité de l'opération est de fait décourageante.

D'autant plus que tu n'as aucune garantie que là où tu vas, tu vas y rester éternellement (pareil, la boîte peut faire faillite, tu peux être viré ou vouloir changer de boulot). Tu vas répéter l'opération systématiquement ? Cela me paraît lourd, stressant, financièrement risqué (car quand tu veux revendre vite, en général ton prix de revente est plus faible que celui d'achat).