freem a écrit 5059 commentaires

Pas entièrement faux, sauf que je dirais plus que le problème viens de tout baser sur un framework, pas de la multiplication des dépendances.

Exemple: j'utilise wxWidgets pour un truc. 5 ans plus tard, nouvelle version majeure est arrivée.
Version majeure, cassage de l'api, normal. Donc, soit j'évolue et maintiens mon appli, ce qui peut ne pas coûter trop cher si je l'ai fait au fur et a mesure, soit je reste avec l'ancienne version. Vu que je me suis basé sur une lib open source, je peux même la maintenir moi-même.
Mais dans le 1er cas, il m'aura fallu maintenir l'application entière, parce que j'ai utilisé une usine à gaz qui fait même le café.

A contrario, si je fait la même chose, mais en utilisant des lib spécialisées pour les tâche, en divisant l'application en modules qui ont chacun leurs propres dépendances, je me retrouve avec une appli plus dure à construire, mais dont la maintenance sera plus aisée, car les maj majeures des libs n'affecteront qu'un seul module, et n'iront pas toucher le coeur de l'application (qui a été créé parce qu'il n'existait pas, sinon on aurait pas réinventé la roue, pas vrai?).

Par contre, les vieilles applis vivent plus vieilles, parce que la force de l'habitude est dure à détruire. Ca vaut pour le matos, il suffit de regarder le layout clavier universel ;)

PS: Ca marche aussi avec Qt, MFC, …
PPS: je me rattrape de dredi :P

J'ai récemment récupéré une machine certifiée pour windows millenium. J'ai vu plus vieux, mais ça a fini par tomber en rade :D

Bref. 64Mo de ram à l'origine, un disque dur de 10Go et w2000 Nt promptement remplacé par debian testing, avec i3 en gestionnaire de fenêtre, uzbl dans le rôle du browser.
Ben, c'est plus rapide que windows 2000, c'est certain (celui-ci n'étant pas capable d'accéder au net avec son IE4 :P). Et pas de souci d'installation non plus…

Depuis, j'ai chipé dans un coin une barrette de 128 qui manque sûrement pas à son propriétaire (vue la quantité et la couche de poussière qui l'environnaient…) et remplacé le disque par un 80. C'est mieux malgré tout…

Par contre, le boot est long, on à même le temps de voir le tableau qui récapitule le matos, après le POST du BIOS :D
En fait, je crois que le temps que cette machine arrive sur grub, une de mes quotidienne arrive à démarrer presque entièrement. Et j'ai pas de ssd…

Maintenant, c'est sûr: si tu colles du gnome3 avec bloatuntu, y'a pas de risque de pas swapper.
A vieille machine, logiciels minimaux ou alors tu te prends une swap en pleine poire, pire qu'une baffe :P

On utilise plus volontiers des langage de très haut niveau, tout est développé en objet, sans parler des >langages de scripts qui sont de plus en plus utilisés également, tout ça fait que les applications sont >foncièrement plus lente car tout cela combiné multiplie le nombre de cycle processeurs pour faire des >choses simples.

Le point en gras n'a, à mon très humble avis, rien à voir avec le fait que les gens codent comme des porcs.

J'ai, personnellement, une anecdote, un souvenir de BTS relativement frais (même pas 10 ans).
Dans ce souvenir, le prof disait qu'on se fout d'utiliser un int (par défaut, ça veut dire un signed long, si je ne m'abuse) pour stocker à nombre de 0 à 10 plutôt qu'un unsigned char…

La conséquence, très simple, c'est qu'une appli consomme 4 fois plus de mémoire en 32 bits (long => DWORD => 4 octets) et peut-être (trou de mémoire, l'asm auto-didacte remonte à loin) des instructions plus complexes pour la manipuler parce que c'est un signé.
A partir de là, pourquoi ne pas prendre un double (nombre réel le plus précis) pendant qu'on y est!!!

Mon chef actuel m'a aussi raconté que les gens ne font plus attention à ce qu'ils utilisent comme type dans les tables de bases de données.

Plutôt que de taper sur un paradigme, une façon de penser propre (qui est tout aussi propre que les autres, d'ailleurs, juste plus à la mode) il serait peut-être temps de remettre en cause les dev eux-même, ceux avec les diplômes d'ingé…

En revanche, oui, java, C#, obj truc… et les frameworks de dev C++, je pense qu'on en fait une surconsommation. Cela dis, quand le temps de dev est divisé par 10, on peut aussi le comprendre. Nombreux sont ceux qui ne dev pas, ou ne dev plus, par plaisir, j'ai l'impression.

Signé: un dev de 26 piges, qui a appris tout seul et à tellement fait le con au bts qu'il l'a pas eu et n'est donc pas une référence :D

Y'a que moi qui fait un buffer overflow en lisant que tu râles après la performance merdique des softs modernes et que derrière tu estimes que python est un meilleur choix que C++/Qt?
Faut m'expliquer la…

Bon, pour le reste, je pense qu'effectivement ton dev à commis une erreur: le framework graphique devrait se limiter aux graphismes. Maintenant, Qt, c'est presque un langage en soi (et devinez pourquoi j'aime pas…)

Après, ça dépends aussi des spéc que tu demandais. La cible était windows only? Ben, utiliser l'API win32 aurait permis une compatibilité pour les années à venir, et elle est plutôt complète.
Ah, ça devait être portable? Hum, la, c'est un fait, c'est tout de suite plus dur de trouver quelque chose qui ne bouge pas en fonction des OS sur lesquels ça marche.

Après, problème dû à un changement de version? As-tu tenté de compiler la version de Qt d'origine? Ben oui, quand on passe des version X.a.b aux versions Y.c.d ça implique traditionnellement que l'on casse l'API publique, c'est bien connu et la plupart des dev suivent cette méthode. A noter que souvent, le 3ème chiffre permet de conserver la compatibilité binaire, chose qui n'arrive que rarement avec le 2nd.

Et pour le fait de retoucher des trucs qui marchent, je trouve ça normal. Sur une appli que je fais (stade alpha, certes), j'ai un code crado pour le menu, intimement lié aux plug-ins. Ben ça rend la maintenance plus chère, alors je suis en train de réécrire ça (et de tenter de dissimuler mon incompétence de l'époque derrière un flot de commit XD).
Donc, une telle modification à un rôle (au choix, droit de sélectionner plusieurs résultats): booster la perf, faciliter la maintenance, diminuer le couplage avec d'autres composants…
Dans le cas de Qt, il semble que la dernière option ait été un objectif majeur de la version 3 à la 4.

Et je vais finir par la référence au code orienté objet.
Ca me fait définitivement marrer d'estimer qu'un code orienté objet est plus lourd/lent. Pourquoi? Parce que dans les code C, faits par ceux qui aiment pas les classes, on trouve, entres autres:

struct FooBar
{
  ...
};

FooBar* createFooBar(...);
void deleteFooBar(FooBar *);
int getFooXPosition(FooBar *);

Et, je suis navré de vous le dire, mais c'est du code objet, version illisible. A part ne pas utiliser le mot-clé class (et devoir se taper le passage du 1er argument de façon systématique, avec risque de merder sur l'allocation mémoire, bien sûr), il n'y a aucune différence… Enfin, si on adopte un langage dont la mentalité est de pas faire payer pour les trucs qu'on demande pas explicitement (je ne citerai pas de noms pour éviter de déclencher plus de trolls).
L'objet n'alourdit pas le code, il le rend lisible. Et ce n'est pas lié au langage, mais à la façon de penser du dev. De toute façon, tout finit en assembleur, alors rien n'est objet, pas vrai?

P'tet via la bêta?

C'est pas plutôt le rayon électroménager ça?

Troll : Microsoft avait laissé, avec Vista, une chance aux distro Linux pour s'établir sur le desktop, et >recommence avec W8. Les distros Linux avaient complètement loupé le coche en ne faisant rien face à >Vista, y arriveront-elles face a W8? Ubuntu Store et Steam s'y mettent, alors peut-être…

Bizarre, je pensais que tu aurais parlé de gnome3 ou d'unity… /me ->[]

L'avantage d'une merde libre par rapport à une merde non-libre, c'est qu'on peut en changer le parfum en y contribuant.

PS: je n'ai pas regardé le code. En même temps, le ruby, c'est trop cher pour moi je connais pas.
PPS: le PS ci-dessus n'a aucun rapport avec le Parti Socialiste
PPPS: je plussoie la mocheté du site, tout de même. Mais ils ont pas fait moins utilisable que celui de la SNCF (qui reste ma référence en la matière de site inutilisable qui n'atteint que l'objectif publicitaire et pas utilitaire), alors ça va.

J'en doute fort, parce que .NET n'est ni plus ni moins qu'un outil bâtard entre le framework et la machine virtuelle de JAVA, selon moi.
Windows, exemple tellement cité, regorge de frameworks faisant le café… donc, les libristes ne sont pas les seuls.

En fait, je pense même que c'est l'exacte raison du succès de JAVA, et de .NET: l'abondance de fonctions au sein de la même merde chose.

Après, pour le reste, effectivement à lire les ressentis envers FF, un dev mozilla qui défends son patron me semble avoir assez peu à dire, au vu de ce que je vois sur DVP.
Après, je suis pas dev web/extensions donc il se peut que je me trompe quand j'ai l'impression que la stabilité des APIs laisse à désirer.
Ensuite, certains points d'intégration ne sont pas complexes à gérer, même sans librairies. (l'emplacement de la conf utilisateur, par exemple, ou il suffit de récup le contenu d'une variable… je serais heureux que plus de logiciels le fassent au lieu de pourrir mon ~/)
J'ignore si FF les respecte, cela dis, cela fait bien longtemps que je ne l'utilise plus. Utiliser une bdd pour stocker des favoris me fais assez tiquer, et de ce que je me souviens c'était un des trucs que FF faisait (sqlite3, ce me semble).

En revanche, pour le côté coup de gueule anti-toolkit… D'une part, je te rejoins, d'autre part je suis pas d'accord.
Les toolkits se sont construits à une époque ou ils étaient nécessaires car tout restait à faire, surtout en C++ qui est un langage (qui me semble) jeune, ayant trop peu d'outils en standard (d'où l'émergence de boost et Qt je dirais).
Donc, ces frameworks, même s'ils subissent les erreurs de leur passé, ont joué, et jouent toujours, un rôle utile, pour créer des logiciels utilisables autant sous windows que d'autres OS. Sans eux, je n'aurais jamais franchi le pas, parce que j'aurai dû découvrir à 100% mon environnement libre, plutôt que de le faire progressivement.

En revanche, je dois admettre que quand j'utilise ces frameworks, je fais mon maximum à utiliser des fonctionnalités standard au maximum: je bannis les XXString, notamment. Et quand c'est possible, j'ai une préférence pour boost, qui est un ensemble de librairies faiblement couplées les unes aux autres.

En gros, je pense que ces frameworks ont eus à trouver des workaround à un langage (C++) trop restreint suffisamment vite pour ne pas être freiné par des normes qui mettent 12 ans à naître (et je n'ai pas parlé d'implémentation).
Mais quand on peut utiliser les normes, je pense qu'il vaut mieux oublier les fonctionnalités équivalentes du framework. Une des raisons majeures pour lesquelles je n'aime pas Qt par exemple, c'est la modification de la chaîne de compilation. Mais je dois admettre qu'un soft Qt est portable et bénéficie de perf correctes… tant qu'il ne s'agit pas d'un truc KDE, qui impose de télécharger VLC-nox pour un émulateur de terminal…

Le problème, ce ne sont pas les frameworks, mais les environnement de bureau qui n'arrivent pas à faire des choses modulaire. Ce n'est pas du tout la même chose. (j'aimerai qu'on m'explique pourquoi un terminal doit installer un module son, qui lui-même dépend de vlc, le tout impliquant finalement d'installer phonon, dépendant de… je parle de Qt, mais gnome est pareil sur ce point)

J'ai dis le problème? En fait, non, c'est la conséquence. Le problème, c'est que l'on veut tout faire à moindre effort. Ce qui inclue l'effort de moindre conception. Ce qui génère un couplage fort d'éléments qui n'ont pas une utilité vitale (sérieux… coupler vlc et un terminal…)

Ben, disons que c'est dans la même veine qu'écrire sur 2 membres d'une union à la suite: ça marche, mais ça laisse présumer du meilleur… ou du pire.

N'empêche, marrant que des dev capables d'accepter ce … truc… inqualifiable sur les union aillent reprocher au C++ leur bouletitude.
D'un autre côté, j'ai l'impression que les dev C qui critiquent le C++ ont partiellement raison, certains de nos confrères font du boulot de porc et se servent des capacités qu'apporte le C++ pour ça, donnant l'impression que C++ est la cause.

PS: ceci peut ressembler à un troll car je me suis contenté de lire l'article et les commentaires, jusqu'a ce point. Ah, non, j'ai aussi été voir leur site pour chercher à quoi ça sert cette lib, et j'ai pas trouvé (par contre j'ai très vite trouvé qu'ils parlaient de changer de manière de procéder en fonction de ce que les utilisateurs sont près à payer pour plutôt que les choses que les dev supposent utile. A méditer.)

Merci donc au premier commentateur qui l'a précisé.

Le choix du boot loader, je l'ai déjà. (me suis pas fait prier longtemps pour placer lilo par exemple)
Du côté des dépendances, ça fait justement partie des raisons qui font que j'ai envie d'utiliser gentoo. Il y a peut-être un peu moins de liberté, mais ça semble déjà assez énorme, pour apprendre, non?

Je me demande quand même…
Des langages compilés comme le C++ (dont je pense que la quantité de lib est plus importante) ne recense que 4-5 libs portable pour les graphises. Et je n'en connais pas pour l'intégration avec l'explorateur.
Windows en a un standard, mais chaque DE, voire utilisateur, linux possède son propre explorateur de fichiers.

Du coup, je vois compilation conditionnelle pour MAC/Windows/Linux, et derrière, détection automatique du DE et adaptation en "live"… J'espère qu'azarius sait faire tout ça, parce que ça me surprend de la part de delphi? (langage fermé, tout ça tout ça)

3 ans de dev? (dernière version avant celle-ci : 2009 selon wikipedia)

Sinon, il y a aussi de pouvoir avoir le même logiciel sur tous tes OS, puisque super n'est dispo que sous win.

Bon, je sais, on est pas vendredi…

J'ai bien ouï dire qu'il existe un travail sur un compilateur delphi capable de produire un exécutable ELF, mais cela ne risque-t-il pas d'être long d'adapter un code pas prévu pour être portable?

Vu qu'il semble, vu sur wikipedia, qu'ultracopier soit en C++/Qt, je me demande comment vous allez faire pour adapter un code delphi non portable vers du C++?

Ma question n'est pas que trollesque, je suis vraiment intéressé par ça, surtout qu'il semble que vous souhaitiez migrer des fonctionnalités de super vers ultra, donc, de Delphi windows à C++ portable. A Qt près, j'ai été soumis à la même problématique sur un soft, bien que n'ayant pas réussi à compiler le programme delphi, j'ai pris le parti de reprendre from scratch… (surtout étant seul, pas trop envie de me taper l'apprentissage d'un langage + du fonctionnement interne d'un logiciel)

Mais naturellement, c'est une distinction, ainsi on montre que la femme est tellement inutile sauf à garder les gosses et faire le ménage…

Cela dis, ces valeurs doivent se perdre de nos jours moi j'dis.

Franchement, merci pour cette tranche de rire

Je suis d'accord…

Sur la reprise d'autorealm, il m'est arrivé à plusieurs reprise d'expliquer du mieux que je pouvais le problème que j'avais sur les mailing list d'autorealm, pourtant pas forcément pleines de dev ni très actives, et certains utilisateurs m'ont répondu, me donnant des idées.
Parfois même en faisant un rapport de progression de mon travail (alors qu'étant le seul dev je n'y était pas contraint)

Un exemple tout bête, en apparence, comme contribution, mais je n'aurais pas réussi à gérer la sauvegarde/le chargement des fichiers sans ça:

J'ai un système de plug-in qui impacte directement sur le modèle de données, ça implique de sérialiser des choses qu'on ne connaît pas, et donc d'identifier à la désérialisation des choses qu'on ne connaît pas encore.
J'étais "parti" (mais sans y arriver) sur un système d'identification unique des plug-ins via leur nom et leurs versions, j'ai expliqué ça sur la mailing list des utilisateurs, et quelqu'un m'a dit, en gros:
"Je suis pas calé sur ça, je ne connaît pas les contraintes en terme de dev, j'ai pas envie de plonger dans le code, mais je pense que ton idée va être très chiante à gérer pour les utilisateurs. Pourquoi ne pas demander au plug-in de nommer les choses qu'ils savent faire, et quand le moteur sauve un fichier, écrire dedans le nom de la fonctionnalité? Quand le moteur charge, il a juste a récupérer le nom de la fonctionnalité et trouver un plug-in qui la supporte."

Et la, paf, ça a fait des chocapics. Grâce à son idée, j'ai réussi à implémenter un truc qui me résistait depuis plusieurs semaines, avec un système pourtant super répandu sur le net: les tags.

Comme quoi, j'irai même dire qu'il n'y a pas besoin de savoir dev pour contribuer au code, parce que c'est ce qu'il a fait indirectement.

Je pense que la question olfactive n'est pas le principal point du journal…

Imaginez comme ça doit être le pied de marcher à nouveau pour lui…
Bon, par contre, il risque de mettre les pieds dans le plat à la prochaine réunion des unijambiste en colère.

Maintenant, le libre c'est aussi respecter le travail des autres, même si leur travail nous semble >inutile ( il est peut être utile à d'autres). Et d'ailleurs je suis curieux de savoir à quel(s) projet(s) >tu contribues ?

Je pense qu'il doit contribuer à un projet de langue française simplifiée. (hé oui, comme tu le soulignes, c'est vendredi)

Et puis au passage, pour avoir osé dire qu'aucune distribution n'est partie de 0, on devrait le féliciter de sa clairvoyance. C'est une évidence, les distributions GNU/Linux ont toujours une base, même la première. Ca s'appelle un dieu, je crois.
Et si on en connais pas le nom, c'est parce qu'il est dit dans les commandements qu'on ne doit pas lui en donner, naturellement :D

Sinon, pour redevenir un peu sérieux, je me demande, à ton avis, il faudrait à peu près combien de temps à une personne qui n'a jamais compilé de noyau pour avoir une distribution BLFS utilisable? Hors temps de compilation, bien sûr, je parle plus en temps de lecture / compréhension des ouvrages en question.

Parce que certains points m'ennuient dans Debian (la seule que je connaisse) et que de toute façon j'ai décrété que la prochaine sur la liste sera une distro source. Alors, je me dis, tant qu'a compiler, autant le faire de façon ludique, et BLFS me semble une candidate intéressante.

PS: dans les points ennuyeux, en vrac:
* grub l'usine à gaz dont l'utilité me semble discutable (je change pas de kernel ni d'OS tous les jours, alors une config aussi difficile à gérer pour un truc statique?)
* sysvinit et ses multitudes de scripts qui rendent dynamiques des choses qui sont fixes sur ma machine
* les dépendances à des choses que je ne pense pas utiliser
Et, oui, je sais: gentoo me permettrait de m'en passer, sûrement. Mais je suis curieux de savoir malgré tout le temps qu'il faut pour avoir une BLFS fonctionnelle…

2) leur code ne serait pas commité s'ils refusent les règles (libre à eux de forker s'ils pensent que >c'est la bonne solution).
Et c'est là que le bazard arrive, justement, genre, je sais pas, les dernières évolutions de gnome et les forks qui en découlent?
Au final, même le dev en bazard n'évite pas le fork, parce que tout connement, peu importe la méthode de dev, il y a toujours quelqu'un ou une minorité qui a l'ascendant sur la communauté… comme Linus Torvalds l'a sur Linux (et Lennart sur systemd? aborder cet outil finira par donner le droit au point godwin huuhu)

Mais certaines grandes lignes pourraient devenir communes et on verrait apparaître des standards de >fait.
Les distros obéissent à ce point pour certaines choses:
_ redhat et ses filles => rpm
_ debian et ses filles => deb
_ toutes celles que je connais (pas besef) => Xorg

Un modèle encore plus haut serait de passer par POSIX/LSB/Freedesktop pour plus de choses encore.
Voir plus haut.
Sauf que:
1. POSIX ne sera pas respecté par les gens: coûte trop cher, et même GNU considère ça comme de vulgaires conseils (http://www.gnu.org/prep/standards/html_node/Program-Behavior.html#Program-Behavior). Déjà que je les trouve ridicule avec leur "C only" (http://www.gnu.org/prep/standards/html_node/Source-Language.html#Source-Language) alors … bref.
2. LSB ne semble pas spécialement motivé pour prendre en compte l'avis de tous (http://en.wikipedia.org/wiki/Linux_Standard_Base#Criticism)
3. FreeDesktopOrg ne propose que des spécifications (http://fr.wikipedia.org/wiki/Freedesktop.org). Cela dis, j'ai l'impression qu'elles sont souvent suivies que les 2 normes sus-citées?

Mais tout ça n'empêche pas que le bazard ou la cathédrale m'avaient toujours semblé s'appliquer au dev d'un seul logiciel? Pas d'un OS complet et des multitudes de logiciels qu'il inclue, et c'est la "faute" des dev qui ont tous différents besoins… Je me vois mal obliger les dev de firefox à utiliser telle librairie gérant la sérialisation plutôt que boost::serialization, par exemple.

Ben, pour autotool, perso, j'ose pas apprendre à m'en servir.
Dès que je regarde le contenu de ces choses, mon PC mets une musique d'outre-tombe, la lumière diminue et prends des reflets de rouge sang, ma chaise et mon velux claque…

CMake, j'avais peur aussi. Mais quand j'ai regardé un fichier la première fois, aucune ambiance inquiétante ne s'est déclenchée, alors j'ai même trouvé et résolu le problème que je cherchais en moins de 10 minutes.

Avec les récents développements de Gnome3, Unity, systemd (etc.), on peut se demander si le modèle du >bazar amène autre chose que du bazar…

il suffit de remanier la phrase pour comprendre sa pensée:

on peut se demander si le modèle du bazar amène
==> amènent-ils
Ce qui nous donne: "les récents dév […] amènent-ils du bazard?
Traduction et super raccourci trollesque:
Les récents dév de […], c'est le bordel
(perso, j'en sais rien, j'en utilise aucun ⁾

Hé bien tu sais comment contribuer un paquet à debian alors :P
Compilation, packaging, envoi au mainteneur, je suis sûr qu'ils seront preneurs.

/me se demande ce qu'ils ont fumé…

Il y a des gens qui vivent à 10m d'une voie ferrée. Lequel est le plus chiant? Je vote pour la voie ferrée.
Idem pour les autoroutes et encore pire pour les aéroports.

Continuons sur le fait que le vent dans les arbres, ça fait du bruit aussi, et aux dernières nouvelles, les vaches, poules (surtout les coqs xD), moutons et ânes, ça fait un boucan du diable. Je n'ai pas évoqué les chiens…
Entre toutes ces "nuisances" que l'on peut trouver à la campagne et le bruit régulier, que l'on finit donc par oublier, des éoliennes, l'argument sonore me parait peu pertinent.
Ca me fait toujours penser aux citadins qui débarquent en campagne et portent plainte contre les église pour tapage… s'ils veulent du silence, mais qu'ils se crèvent donc les tympans!

Au passage, ceux qui habitent à 50m de la côte, par chez moi, ils savent que leur maison c'est du consommable: 50 ans plus tard, la moitié se casse la gueule de la jolie falaise ou elle était perchée mouhahaha (bon, naturellement, ça ne vaut pas pour tous)

A mon très humble avis, les ampoules àlaconsuperchèresquigrillent3foislan sont tout sauf éco (logique/nomique):

• ça coûte un pognon monstre à changer, bien plus que les classiques
• ça implique très probablement (on est trolledi alors j'ai droit de pas être renseigné très précisément, non? D'autant que quelqu'un les a déjà cités) des traitements chimiques lourds pour les produire
• celles de mauvaise qualité nécessitent un temps pour chauffer. Pas très utile dans les lieux de passage (genre les chiottes pour peu qu'on en supprime la collection de magasine pr0n de geek de jacky) ou les couloirs, comparé aux ampoules classiques.
• ça grille souvent! J'en ai changé au moins 4 dans ma piaule cette année bordel!!! Combiné au coût en € et en carbone à la prod, je doute que ce soit si "éco".

Pour le reste, au sujet de l'isolation, par exemple, j'aimerai porter à votre attention 2-3 faits:

• une fenêtre très isolée va souvent impliquer, au choix, plus de couches de verres, des gaz ou des intercalaires. Chaque couche va améliorer l'inertie thermique de la fenêtre, ok, mais elle va aussi augmenter son opacité, qui résultera en un allumage des lumières plus tôt en hiver.
• une bâtisse très isolée (qui signifie que la température passe mal d'un sens comme de l'autre) implique que l'on chauffera moins en force, mais plus longtemps. Si la bâtisse est utilisée en permanence, comme l'est une usine, par exemple, alors c'est excellent. Sinon, ce n'est pas si sûr: plus il y a d'inertie, plus il faut de temps pour chauffer les murs, donc plus d'énergie.
• les énergie dépendant de l'environnement, elles dépendent de là ou l'on habite. En Normandie (du moins sur ses côtes) l'éolien, ça marche sûrement très bien, en revanche, le solaire, j'ai quelques doutes (on se tape des nuages quasi toute l'année)
• certaines bâtissent utilisent leur forme, leur placement et leur exposition pour limiter leur consommation électrique. D'ailleurs, ces techniques étaient plus utilisées par "les anciens" que nos parents et grands-parents… Ces techniques reviennent un peu d'ailleurs, dommage qu'on aie perdu une bonne partie de ce savoir.
• le bois est plus efficace que l'agglo. Mais il faut l'entretenir à l'aide de produits. Quelle est la toxicité de la lazure par exemple (ceci est une vraie question)?

En gros, je pense que:

1. chaque environnement favorise une écologie différente (le solaire doit cartonner au sahara, et les pools d'éolienne en mer me semblent être une idée plutôt bonne)
2. l'usage fait du bâtiment modifie la façon dont il peut être écologique

Conclusion, l'écologie, on cherche tout le temps à nous faire croire qu'il existe une panacée, mais la réalité, c'est que chaque endroit doit trouver sa façon d'être vert. C'est pas en collant des ampoules à la con partout qu'on y arrivera, et éteindre la lumière dans les ascenseurs est une idée stupide, entres autres.

M'enfin, ça change pas que l'idée d'éoliennes libres est bonne. Reste à expliquer dans quels endroits leur utilisation l'est vraiment, histoire d'avoir un rendement réellement utile…