arnaudus a écrit 4647 commentaires

Sans compter que porter le discrédit sur une décision de justice est un délit. T'as le droit de dire que tu ne comprends pas, que tu n'es pas forcément d'accord, mais que "ah ah le juge c'est pas un vrai juge alors la décision je me torche avec", c'est passible d'une grosse amende et d'une peine d'emprisonnement.

Toute l'affaire se résume bien au fait que la vente liée n'est pas si évidente que ça. Comme ça a été dit plus haut, tout dépend à quel niveau tu regardes; au niveau du supermarché du coin, c'est clair qu'il y a vente liée. Par contre, la grande majorité des constructeurs te proposent aussi des machines sans Windows pré-installé (ok, ils te facturent la désinstallation, et alors? C'est interdit?). Ils ne veulent pas donner le prix de Windows parce que des contrats avec Microsoft les tiennent par les c..., moi je les comprends; en tout cas, tu fais "prix du PC avec WinWin" - "prix du PC sans OS" et t'auras à la louche une idée du prix des logiciels.

D'autre part, Microsoft et la plupart des constructeurs ne nient pas vraiment la vente liée, mais affirment que cette loi ne peut pas s'appliquer décemment avec les PC. Le raisonnement n'est pas à jeter à la poubelle sans le regarder, puisque tout dépend de ce qu'on appelle un "PC qui fonctionne" : est-ce la machine et les ventilos qui tournent, ou est-ce l'ensemble qui doit être utilisable? Le raisonnement s'applique à beaucoup de cas où une information est fournie sur un support, et que le support seul n'a aucun intérêt. Est-ce qu'un disquaire doit aussi vendre des CD vierges, et afficher le prix de la musique et celui du support? Qu'est-ce qu'un gouvernement peut répondre à un distributeur qui dit "La loi m'oblige à vendre les PC sans l'OS si le consommateur le demande. Ça augmente les stocks, les PC sans OS se vendent très peu, ça me coûte plus d'argent de vendre des PC sans OS que ça m'en rapporte. Et en plus, ça m'oblige à afficher les prix et donc à violer mon contrat passé avec Microsoft": tout ça ressemble bien à une loi mal foutue. Tu ne peux pas obliger un distributeur à vendre des trucs qu'il ne veut pas sans contrepartie; il y a d'un côté la liberté du consommateur mais aussi la liberté de commercer sans se faire casser les pompes par des règlements administratifs qui engendrent des surcouts et qui, au final, ne bénéficient que marginalement à quelques consommateurs procéduriers.

Au fond, je suis d'accord avec le but de cette pétition. Mais les moyens employés sont presque pires que le mal : désinformation, exagération, militantisme extrême, accusations. Bref, vous mettez sur cette pétition une étiquette "anarchistes collégiens", qui ne peut pas vraiment servir à déghettoiser le logiciel libre, et ce qui m'étonne le plus, c'est cette obstination dans la non-écoute des remarques qui sont faites à chaque fois que l'on reparle de cette pétition. Déja que la communuaté du libre ne pèse pas lourd, mais si on s'amuse encore à la diviser, c'est sûr, la DGCCRF va être impressionnée...

Un mode sado-maso tu veux dire? :-)

C'est un premier pas de Ms dans le libre.

Moi à mon Bisounours, je lui fais des bisous
Des bisous sur la joue, des bisous dans le cou...

Bah, la FSF n'en n'est pas à sa première contradiction... En tout cas, je ne la vois pas écarter sa GFDL, malgré tous les problèmes intrinsèques à la licence (non seulement en termes de liberté, mais aussi en termes pratiques pour la réutilisation, la modification etc).

Plus j'y pense, et plus j'ai l'impression que cette initiative sert plus à essayer de faire la nique à Ubuntu plutôt qu'à créer une distrib 100% libre gnagnagna. Ou alors c'est une expérience philosophique, à savoir si on peut recréer Debian à partir d'Ubuntu.

Mais c'est facile de tirer sur l'ambulance. Ils partent avec un projet bancal, tout le monde se fout de leur tronche, ou presque : pas de modèle économique, choix du fork assez discutable, situation conflictuelle (probablement avec Debian et Ubuntu). C'est pas gagné, hein, et des distribs, ça apparait tous les jours et ça meurt tous les jours. Alors laissons-les s'amuser, et jugeons du résultat. Si leur truc est incapable de s'installer correctement sur 95% des ordinateurs du marché, alors on leur laissera à leur branlette intellectuelle. Si ça marche, alors ne crachons pas dans la soupe : à fonctionnalité égales, le 100% libre c'est quand même mieux. Mais bon, pour les intégristes du libre : un ordinateur, pour les gens normaux, c'est quelque chose qui fonctionne avant tout.

La question n'est pas là. Au XXIe siècle, tu apprends à communiquer en anglais ou tu meures. Tu te sors les doigts du c... et au lieu de pleurnicher tu vas prendre des cours d'anglais, comme le font les chinois, les japonais ou les africains. Surtout que lire des pages de man, faut pas déconner, il n'y a pas besoin d'être Shakespeare.

Il faut arrêter de cacher sa paresse intellectuelle derrière des arguments fallacieux : apprendre une autre langue ne peut décemment pas être considéré comme un apauvrissement culturel.

Bon, et en plus, même si les pages de man étaient traduites, les commandes UNIX restent en anglais, les fichiers de conf restent en anglais, les langages de programmation restent en anglais, les jeux de mots sur les programmes restent en anglais, les logs restent en anglais... Connaitre un minimum d'anglais me semble indispensable pour l'utilisation correcte d'un ordinateur.

Donc oui, OK, tu ne parles pas anglais, c'est triste pour toi, mais au lieu de te battre pour que les man soit traduits, tu pourrais plutôt te battre pour que les gamins apprennent l'anglais correctement à l'école.

Sans compter que ça dépend énormément du type de bug. Si le bug c'est une faute de frappe (ça peut être extrêmement bloquant, par exemple un export de fichier "pdd" au lieu de "pdf" <- déja vu, comme bug idiot, dans un produit professionnel en plus), il faudra m'expliquer comment tu justifies plusieurs jours de tests.

Ça dépend aussi de comment le produit en question est codé. Parce que dans une grosse suite bureautique, j'imagine qu'il y a des centaines de modules indépendants. Si l'API est bien documentée, en principe, personne n'aurait dû profiter d'une fonction bugguée pour coder un compensant qui dépend de ce bug pour fonctionner. Et ça de toutes manières, ça doit se "sentir" quand on corrige le bug en fonction de l'importance du composant buggué etc. Un bug qui porte sur le correcteur orthographique, si tu crains des répercussions sur le dessins des cercles à la souris, tu devrais peut-être penser à revoir l'architecture du programme.

Enfin, j'imagine aussi que les bugs sont corrigés en série sur une version instable, puis la release est freezée et testée, avant d'être distribuée au client. Je vois mal des "gros clients" se contenter d'un diff et d'un lien vers le cvs... Je conçois donc qu'une batterie de tests sur plusieurs plateformes etc. peuvent être particulièrement longue (mais elle peut être au moins en partie automatisée, surtout si les releases sont fréquentes, ca doit valoir le coup), mais en tout cas, un bug mineur -> plusieurs jours de tests me semble être une équivalence hasardeuse, et ce même pour un gros projet. C'est peut-être ce qu'on raconte à un décideur pressé pour faire passer une facture salée, mais je reste persuadé qu'il y a des manières de s'organiser en interne pour maintenir la qualité du produit tout en gagnant du temps.

D'un autre côté, comme c'est illégal de produire un outil de contournement des DRM, ça me parait tangeant de développer quelque chose qui va dans ce sens... même si c'est "juste pour regarder comment le fichier est fait M le juge"...

Tu es quand même au courant que ce type de vote n'aura jamais une quelconque légalité? La principale raison, c'est que personne ne pourra garantir que l'électeur n'a pas voté sous la contrainte : tu peux t'assurer que c'est bien lui qui a voté, à la limite par autant de moyens biométriques que tu veux, mais le fait est qu'il est impossible de savoir s'il était ou non seul devant son PC au moment du vote.

Pour les problèmes techniques, ça me parait encore plus délicat. Soit tu donnes l'enveloppe contenant le mot de passe en personne, soit il faut un artifice particulier (du type de ces enveloppes que tu ne peux ouvrir qu'en déchirant des pointillés, ou un code caché derrière un scotch noir qui ne peut pas être recollé).

J'espère ne pas dire de conneries, mais :
* On a N clés C1 distribuées sous forme de mot de passe de manière confidentielle
* On a N clés C2 sans aucune autre info stockées sur le serveur
* On a N checksum S générés par C1 * C2, stockés sur le serveur, et les C1 sont définitivement supprimées du serveur.

Quand on vote, on rentre sa clé C1, le serveur la combine avec toutes les C2 existantes jusqu'à tomber sur un S : il valide le vote, stocke le résultat et supprime le C2 et le S qui ont matché.

Ce qui est sûr, c'est que l'admin du serveur a accès à des données sensibles, mais c'est inévitable, mais il ne peut pas reconstituer les mots de passe. De toutes manières il aura aussi les logs avec les IP etc, donc tu ne peux pas empêcher un point faible de ce côté là. On peut certainement bricoler un truc avec deux serveurs et deux admins différents pour plus de sécurité.

Enfin en fait j'y connais pas grand chose, donc c'est peut-être complètement idiot mon truc.

On peut aussi ajouter qu'XML a le bon goût d'être lisible par un parseur et par un être humain (le périphérique situé entre la chaise et l'écran), surtout si la structure du fichier est bien conçue. Et ça, c'est quand même la classe.

Moi j'aime aussi XML parce qu'il n'y a rien de plus facile que de lire une valeur dans un fichier de 10000 lignes, par exemple avec une expression régulière.

Pour avoir testé, XML c'est quand même la merde par contre pour les gros fichiers.

Je me suis pissé dessus sur "PATH le chemin". En tout cas, c'est mon psy qui va pas être content :-)

Bah non, ça serait trop facile autrement :-) Non, sans blague, je n'arrive pas à comprendre ce qui, dans ma remarque, justifierait ma participation au concours. Je n'aurais jamais eu les idées ni les compétences pour le faire. Par contre, je trouve que certaines idées proposées sont excellentes, et que certaines réalisations graphiques sont excellentes aussi, mais je pense qu'elles ne sont pas forcément dans les mêmes images (à part "ils nous tiennent pas les oreilles", qui n'a pas été promu). Je pense par exemple qu'on obtiendrait quelque chose de vraiment bien en combinant l'aspect graphique du premier avec les barbelés du deuxième, quitte à retirer le verrou. Voila, je viens de participer au concours en donnant une idée :-)

J'imagine que tout a été fait dans les règles avec jury et dessins anonymes et tout? Non, parce qu'en fait j'en aimais bien certains autres. J'imagine qu'il y avait certains critères définis?

Et puis, juste une remarque gratuite, comme ça, en passant : ce qui serait gigantesque, c'est de réutiliser les concepts proposés et de travailler sur l'aspect graphique. Par exemple, j'adore le truc avec les barbelés, mais je trouve que l'image sous-exploite complètement l'idée. Le principe du libre, c'est pas que tout le monde participe sur un projet commun?

Le TLFI dit :

CHIOTTE,Fin de l'objet 1 de la requête (Mot vedette) subst. fém.
Trivial
A. 1. Au plur. Cabinets d'aisances. Aller aux chiottes; le trou des chiottes. La cabine téléphonique du bistrot, (...), si sale qu'on la prend toujours pour les chiottes (CÉLINE, Voyage au bout de la nuit, 1932, p. 297).
Au sing., rare. Ce trou d'homme qui s'éboulait en revêtissant le soldat d'un uniforme de boue où, à chaque relève, l'un ou l'autre restait enseveli comme dans une chiotte sans issue (CENDRARS, La Main coupée, 1946, p. 160).
Au fig., emploi exclamatif. [Exprimant le dépit ou l'irritation en présence d'une affaire désagréable] Quasi-synon. merde. Quelle chiotte! C'est la chiotte! C'était fini l'indépendance! Merde le silence! Chiotte la vadrouille! (CÉLINE, Mort à crédit, 1936, p. 320).
2. P. méton., au plur. Corvée de caserne, consistant à nettoyer les cabinets.

L'usage impose donc le pluriel quand il désigne les toilettes : "les chiottes sont bouchées". "La chiotte" n'est pas incorrecte, mais semble très rare.

Par contre, "une chiotte" est tout à fait correct quand on dit "quelle chiotte ce truc".

On en apprend des trucs...

c'est hyper simple de faire un feu de joie avec un peu de papier et du bois bien sec.

Je suis un gars des banlieues moi monsieur, alors les trucs à la Rahan... :-) Un barbecue, ça s'allume comme une voiture : un peu d'essence, une allumette, et !flash! ça grille. Faut partir en courant, évidemment.

Non, sans blagues, l'alcool faut le mettre avant de foutre le feu, évidemment, sinon tu vas te prendre un retour de flammes. Tu gagnes un temps fou, surtout si le charbon est un peu hunide, et en plus ca te met le feu uniformément sur toute la surface de barbecue.

C'est pas hors-sujet, ça va? :-)

Bah de toutes manières, cette taxe mal ficelée sent l'arnaque depuis le début : c'est comme si on te faisait payer la taxe sur les alcools sur l'alcool à brûler dont tu te sers pour allumer ton BBQ.

Je pense qu'il ne faut pas raisonner de manière individuelle (du style : "Je ne vais pas graver de musique sur ce CD, je ne dois pas payer la taxe"). Il s'agit d'une taxe globale, ciblée vers les gens qui tripotent du "numérique"; en cela, elle est certainement plus juste qu'un impôt supplémantaire sur la retraite de Papy René qui ne fait que regarder Derrick à la télé : si tu graves des trucs, c'est que tu as un ordinateur et tout le matos qui va avec, et qu'il est plus probable que tu fasses des trucs pas très nets avec tes CD. Ça n'a qu'un grossier caractère de probabilité, c'est bête et méchant mais c'est comme ça.

En bref, le fait qu'une entreprise qui grave des Debian ou qui sauvegarde le contenu de ses serveurs toutes les semaines ne puisse pas se faire dédommager, ce n'est pas vraiment une lacune : c'est dans la logique de la loi. Si on dédommage les boîtes, alors on devrait aussi dédommager les particuliers, et je ne vous raconte pas la paperasserie et les milliers de fonctionnaires nécessaires (remarquez, ça ferait baisser le chômage). Pensez à la sécu : vous payez même si vous n'êtes pas malade. Pensez à la retraite : vous cotisez même si vous avez un cancer généralisé à 25 ans. On paye des impôts pour réparer les routes quand on n'a pas de voiture, pour payer les radars automatiques quand on n'a pas le permis, pour couvrir le déficit du Crédit Lyonnais quand on est à la BNP. C'est de la mutualisation de l'impôt, qui apparaît injuste dans ce cas parce que 1) il n'est que partiellement mutualisé, sur un critère assez discutable, et que 2) le fondement même de cet impôt et la redevance versée en cadeau aux producteurs est très discutable.

La simplicité de la GPL (la remettre en cause demande de remettre en cause les principes fondamentaux du droit d'auteur internationnal) et son caractère équitable (pas d'injustice ou d'abus à redresser par le juge) en font une license excessivement solide dans tous les pays du monde, France comprise

Je ne peux pas t'empêcher de penser ça, mais je pense que tu as tort. Ces problèmes d'ailleurs ne sont pas propres à la GPL, mais sont partagés par plusieurs licences libres.

Exemple existant : un gusse vient recopier le contenu de son site Internet sur Wikipédia (c'est de la GFDL, mais c'est le même principe). Comme 99,99% des gens, il ne lit pas la GFDL. Quinze jours plus tard, le gusse s'aperçoit de sa connerie. Entre temps, sa prose a été modifiée, diffusée sur des centaines de sites miroirs, potentiellement distribuée sous forme de DVD ou d'édition papier, etc. Démontre-moi qu'un juge ne peut pas trouver les clauses illicites (cessation à vie des droits de diffusion à des inconnus) de la GFDL comme abusives. Il est évident que le mec ne va pas utiliser la clause de rétractation : ça lui coûterait trop cher. Par contre il peut dénoncer cette cessation irréversible de ses droits.

Exemple n°2 : un groupe de zique de quartier diffuse son premier album sous CC-BY-SA (philosophiquement proche de la GPL). Trois ans après, les mecs signent un contrat avec la SACEM, contrat qui impose que la totalité de l'oeuvre musicale soit gérée par la SACEM. Tu crois qu'un juge ne pourrait pas penser que cette CC et sa clause de non-rétractabilité sur le premier album ne nuit pas au détenteur de la propriété de l'oeuvre?

À cela,tu ajoutes l'histoire des vices cachés (ce qui rend la clause "aucune garantie..." caduque) et tu as un cocktail de failles de sécurité potentielles dans la GPL. Il y a des centaines de moyens d'attaquer une licence comme la GPL. La clause de "redistribution des sources" a été jugée solide dans une ou deux circonstances particulières, soit, mais j'ai du mal à comprendre d'où te viens cette confiance aveugle. Beaucoup s'accordent à dire par exemple que ce qui est lié ou non à une application, c'est quand même très flou. Beaucoup s'accordent à dire que l'utilisation d'applis GPL dans un contexte de service en réseau est une manière assez aisée de contourner la GPL, et qu'en tout cas, la GPL est basée sur des considérations hyper-techniques (liaison statique ou dynamique, threads ou pipes...), et rien ne te dit que tu puisses trouver un juge qui développe du kernel sur son temps libre pour apprécier que cette appli qui utilise un plugin/bibliothèque sous GPL via une interface en LGPL doit être distribuée sous GPL ou non.

Alors oui, la GPL a été écrite par des gens qui connaissent leur boulot. Oui jusqu'ici ses clauses fondammentales ont résisté aux attaques de boîtes de mauvaise foi mal conseillées juridiquement. Mais non, le droit international est trop complexe et les nuances trop subtiles pour pouvoir affirmer que la GPL est valide éternellement et partout. Et non, la GPL n'a jamais subi une vraie épreuve du feu, dirigée par des avocats spécialisés dans les droits numériques, sur des problèmes subtils liés au concept de "redistribution" ou de "liaison à un logiciel sous GPL". Et non, la GPL n'a jamais été attaquée hors des USA sur des points qui sont justement différents en Europe et dans le reste du monde. Jusqu'ici tout va bien, et c'est tant mieux.

Je te souhaite une longue et prospère vie, mais tu n'as jamais entendu parler de trucs comme les accidents de voiture ou les morsures par des chauves-souris enragées? Qui va accepter de changer la licence des softs si une faille est détectée dans la GPL2? Tes ayant-droits? Je comprends ton point de vue, mais je pense que c'est quand même beaucoup plus compliqué que ça.

D'un autre côté, tu prends un logiciel libre, tu remplaces le texte du menu "Enregistrer sous" par "Les XXX sont tous des YYY" (remplacez XXX par Juifs, Musulmans, Énarques, Femmes, Homosexuels etc. au choix, et YYY par porcs, nains qui mangent leurs excréments, etc.), tu n'as plus le droit de le diffuser, donc il n'est pas libre ?

La liberté de diffusion sous-entend le fait que les modifs que tu as faites sont licites. Donc tel que tu le poses, je ne vois pas vraiment le problème.

Oui mais attention : si ce n'est pas le cas du noyau, de très nombreux programmes sont diffusés sous "GPL 2 ou version supérieure, à votre choix", c'est à dire au choix de l'utilisateur. J'ai toujours trouvé problématique cette question impossible à trancher : si on release en GPL2 strict, on expose de futurs utilisateurs et développeurs à des attaques ciblées si des failles dans la GPL2 sont démontrées. Si on choisit la GPL2 ou supérieure, on s'expose à des boulettes de la FSF dans les versions postérieures. Par exemple si tu as un brevet sur ton code, tu releases en GPL2>, quelqu'un reprend ton code et le diffuse en GPL3, que devient ton brevet?

Par ailleurs, il me semble important de discuter de la GPL3 qui est le futur du logiciel libre. Apparemment, pour la FSF, il est hors de question de forker la GPL à la manière des CC, donc autant avoir un consensus autour d'une GPL 3.

Bon, d'un autre côté, les graphismes non libres semblent 1) très marginaux, et 2) très temporaires. C'est plus une erreur de jeunesse qu'autre chose...

C'est amusant de voir ce troll littéraire resurgir de temps en temps, alors que l'Académie (pourtant traditionnelle par nature) considère depuis un sacré bout de temps que les formes "respectant" de pluriel de la langue d'origine doivent être considérées comme pédantes.

Le problème, c'est que la plupart du temps, les formes latinisées ne sont pas des latinismes, mais bien malheureusement des anglicismes, puisque la conservation du pluriel d'origine est très courante en anglais.

En Français du XXIe siècle, on dit donc des scénarios (avec un accent), des aquariums, des saunas, des ferrys (des lobbys, etc.), des locus, des maximums (optimums, forums...). Sauf si on est pédant :-)

Ce qui est certain, c'est que la GPL sera probablement invalidée (ou tout du moins une certaine partie de ses clauses) en France si le plaignant est l'un des auteurs du soft. Deux raisons:
* Le Code de la propriété intellectuelle prévoit une clause de rétractation, même après publication (sous réserve de dédommagement, mais je ne sais pas comment ça pourrait se faire : le dev qui souhaite rétracter ses contributions devrait payer quelque chose au projet? Aux utilisateurs?)
* La jurisprudence condamne clairement les contrat de cessation des droits dont la durée est abusive. Et là, "à vie", ça me paraît clairement abusif.

Donc la GPL est probablement minée en France si un particulier (ou plus embêtant, une entreprise) a contribué à un soft sous GPL et regrette sa contribution plus tard. C'est plutôt embêtant.

Par contre, je n'ai jamais entendu parler de failles potentielles de la GPL si le plaignant est un simple réutilisateur et/ou distributeur du code. Des infos là dessus?

C'est vrai, ces projets sont "semi-libres" : la licence des logiciels est libre, mais l'accueil de la communauté n'est pas à la hauteur de ce qu'on est en droit d'attendre pour un projet libre. Mais au lieu de hurler sur les comportement des uns et des autres, pourquoi ne pas s'"extasier" (bon, OK, c'est un peu fort) sur la puissance des licences libres et des possibilités qui sont offertes aux utilisateurs? On est typiquement dans le cas où le comportement du dev déplait aux utilisateurs (que son comportement soit justifié ou non, c'est une autre histoire). Même "semi libre", même avec des marques déposées assez contraignantes, un fork est possible, et rien n'est perdu, à part du temps et des méga-octets de trolls.

La compétition est aussi ce qui fait avancer le libre. Si Nvu déconne, si sa redistribution n'est pas facile, si le soft est buggé et ne bouge plus, alors les distributions vont commencer à intégrer le fork, à reporter les bugs à la version forkée, des dev indépendants vont se sentir mieux accueillis et vont proposer des améliorations, et le fork va se développer plus vite, mieux, autour d'une communauté mieux structurée. Si au contraire Nvu 2.0 déchire des mamans ours lors de sa sortie, KompoZer va progressivement tomber dans l'oubli. Si les deux projets sont de bonne qualité et complémentaires, alors on aura le choix d'installer l'un ou l'autre selon ses gouts ou l'utilisation qu'on compte en faire.

Au final, le gagnant est définitivement l'utilisateur. La compétition entre projets libres, même hostile, reste néanmoins extrêmement stimulante en termes de qualité et de développement d'une image forte (killer features, améliorations de l'ergonomie, de l'aide etc). Donc c'est peut-être dommage de dupliquer les efforts, mais c'est aussi comme ça que le libre avance.

Les langages de programmation (enfin les "vieux") ont été conçus à une époque où on n'avait pas de recul sur les gestions de versions, sur les éditeurs de texte, sur la diversité des conventions, etc. Ils trainent donc des erreurs du passé, et le mélange fond/forme dans un fichier source, c'est AMHA une erreur de conception profonde du langage. Les sauts de ligne faisant partie de la forme (et malheureusement parfois du fond), ils sont traînés comme des boulets depuis 20 ans.

Error: helloworld.c:1 : c'est évidemment un bug du compilateur. Ça serait beaucoup plus logique qu'il indique le caractère dans le fichier qui pose problème, et pas la ligne.

Ce que je veux dire, c'est que le système a une inertie terrible : 1) les langages de programmation existants prennent parfois en compte des informations de mise en page du code, 2) les éditeurs savent très mal travailler l'indentation d'un fichier, 3) les programmeurs sont probablement encore plus intertes que le reste de l'humanité, et faire changer ses habitudes à un programmeur, ca doit être au moins aussi stimulant intellectuellement que de faire rentrer des notions de politique internationale dans la tête de G. W. Bush. La conclusion de ça, c'est que dans 30 ans, les fichiers seront encore indentés à la main ou très mal indentés par un éditeur, les languages (comme C++++) prendront toujours en compte des informations de fond pour fabriquer du sens, il faudra toujours un bac +30 pour faire fonctionner les autotools (dont la version 37.8 sera bien entendu incompatible avec la 37.7, elle même incompatible avec la 37.6).

Mais ça me rend juste triste de voir qu'il faut implémenter des workarounds sales dans les svn en 2006 parce qu'il est rigoureusement impossible de comprendre qu'un gusse a remplacé une tab par 8 espaces. Ça me rend aussi triste de voir que des projets comme Gnome ou KDE (et probablement des centaines d'autres) continuent à se prendre la tronche et donc à perdre un temps fou sur la définition de normes pour l'indentation, alors qu'encore une fois ça serait tellement simple si ça pouvait être géré par l'éditeur de chacun, en fonction des préférences de chacun, mais seulement à l'affichage, puisque c'est bien de ça qu'il s'agit, et pas dans le fichier source lui-même. Tout ça parce qu'on traine les erreurs du passé, comme un boulet au pied auquel on est tellement habitué que ça nous ferait presque mal de nous en débarrasser.

Bon, j'y ai peut-être été un peu fort sur les sauts de ligne, mais je reste quand même persuadé que le saut de ligne est un caractère "forme" et pas "fond", tout comme l'espace et la tabulation.

Utiliser un éditeur de texte qui ne sait pas lire le code, par exemple Word, pour lire un fichier C, ne rendrait pas le truc illisible :

int main(int argc,char** argv){printf("Hello Word!\n");}

reste quelque chose de "compréhensible" (bon, c'est sûr, si le fichier fait 200ko, ça va être moins lisible...). Mais ça reste du texte, et ça ne compromet en rien la lecture, la modification, la recherche de chaines de caractères etc. Mais la mise en page est neutre, et c'est à l'éditeur de texte, si l'utilisateur le veut, de remettre ça en page pour faciliter la lecture et l'édition. Donc je persiste à dire par exemple qu'en C, le saut de ligne est un caractère de mise en forme, il n'a aucun sens (autre que celui de séparateur, et malheureusement, de fin de commentaire pour les // du C++). Au passage, cette "suppression de tous les caractères inutiles avant publication" est courante pour le HTML, je ne vois pas pourquoi ça ne pourrait pas se faire pour les autres languages.

L'informatique n'échappe pas à la tendance naturelle à l'immobilisme : si un gars s'est fait chier 20 ans avec les Makefile merdiques, il va voir d'un mauvais oeil l'apparition d'une nouvelle syntaxe qui va tout révolutionner.