arnaudus a écrit 4598 commentaires

Pour moi, demander à quelqu'un de monter une chaise, ce n'est pas monter une chaise.

Soit j'ai loupé un épisode, soit cet argument est complètement débile. C'est la même chose que de dire que C++ est compliqué parce qu'il est difficile de coder un compilateur C++. Et qu'utiliser g++, c'est de la triche.

J'imagine que tu as donc codé ton OS, tes drivers, tes compilateurs, ton bureau, et ton navigateur?

Non seulement réinventer la roue est coûteux en temps, mais c'est aussi complètement stupide pour des raisons d'efficacité (bugs et optimisation). Alors oui, la programmation, la plupart du temps, c'est de l'assemblage d'algorithmes déja faits. Je ne suis pas certain qu'apprendre à faire du tri à bulle soit une compétence valorisable, c'est un exercice intéressant, mais savoir faire ça n'est probablement pas, la plupart du temps, quelque chose d'important. Ceci dit, il existe des milieux où la masturbation intellectuelle est bien vue, mais en ce qui me concerne, si j'ai à choisir entre deux étudiants, que je leur demande de trier un vecteur, et qu'un me recode un algo de tri tandis que l'autre m'écrit une ligne où il appelle un sort(vector), sans hésiter, je prend le second.

OK, on le refait avec le contexte :

Remarque: Mieux vaut un format simple parce qu'on peut coder facilement son propre parseur
Réponse: Personne de sensé ne code son propre parseur, mieux vaut un parseur XML validé par la communauté qu'un parseur maison non testé

Donc non, ce n'est pas une obligation d'utiliser XML, personne n'a jamais prétendu ça. C'est juste que l'argument du parseur compliqué est bidon.

Et pour revenir, sur un point, oui quand le moteur se coupe pour un défaut de relais de puissance sur les injecteurs, en virage, et donc que l'on a plus d'assistance a la direction, ni au freinage, qu'il fait nuit (heureusement les feux sont resté allumé), que l'on est un peu crevé … c'était limite le crash.

Nan mais personne n'a jamais dit le contraire. Tu es en train de rouler, et d'un coup, tu pers l'assistance au freinage : évidemment tu vas te planter au premier virage. Tu n'es pas pilote de ligne, tu n'as pas de checklist et tu n'apprends pas par cœur des séries de tests à faire dans le bon ordre pour réagir comme il faut à tout un tas de pannes imprévisibles.

On parlait d'une situation tout à fait différente : un type qui a une double panne improbable (blocage du régulateur à très haute vitesse ET perte de l'assistance au freinage) sur autouroute, et qui a plusieurs minutes pour réagir. Et là, il fait quoi? Il appelle les flics. C'est une vaste blague, n'importe qui essayerait de reprendre le contrôle de la bagnole avant, et comme dit plus haut, il existe 3 à 5 trucs évidents à essayer, dont deux (rétrograder et passer au point mort) ne peuvent pas ne pas fonctionner (certes, au risque de flamber le moteur).

Le truc, c'est que le contexte est crédible : en effet, on a de plus en plus d'électronique dans les bagnoles, en effet, les systèmes sont assez buggés et que dans certaines circonstances, les pannes peuvent être dangereuses, en effet, les constructeurs semblent aimer retirer des mécanismes physiques simples pour les remplacer par des transmissions électroniques, et qu'un jour il faudra bien assumer de mettre quelque part un coupe-circuit avec un gros bouton rouge. Tout ça est vrai, et c'est en effet inquiétant, mais ça n'enlève rien au fait que les circonstances de ce fameux "incident" font qu'il est objectivement impossible de valider la version du conducteur. Le mec est un menteur, ou il était shooté, ou il a fait n'importe quoi, mais la panne qu'il décrit est simplement impossible.

Ouais, il a carrément retiré la clé, quoi…

Dans la panique, tu peux aussi décrocher ta ceinture, ouvrir la portière, et te jeter dehors. ou appuyer sur tous les boutons. Ou ouvrir le capot avec la manette. Tout ça me semble plus crédible que d'appeler les flics pour qu'ils ouvrent la barrière de péage…

Compresser un fichier XML, c'est un non-sens, parce qu'on perd l'un de ses intérêts principaux

Je ne pense pas que ça soit juste. Un fichier texte se lit avec un logiciel, la distinction texte/binaire est symathique au quotidien, mais elle n'a pas vraiment de sens en informatique. Ce que tu appelles un fichier texte, c'est juste un ficher binaire que tu peux lire avec un décodeur binaire -> ascii (vim, emacs, less, ou libre office, pas très important). Ça prend à peu près 5 secondes de créer un alias "zipless" qui va te lire les fichiers compressés sans quetu t'en rendes compte, c'est juste un réencodage de fichier ascii sous un format compressé. D'ailleurs, il existe des systèmes de fichiers qui gèrent la compression et décompression à la volée… bref, c'est un non-argument. Un fichier zip ou un fichier txt, c'est juste deux moyens de stocker un fichier xml, l'un étant plus efficace que l'autre en terme de stockage, l'autre étant plus efficace en temps d'accès.

Ou alors, les devs se sont tapé l'écriture d'un parseur XML à la main et on la flemme d'en écrire un autre.

Ou alors les devs ne sont pas des gros blaireaux et ils utilisent libxml ou autres bibliothèques codées par des gens qui savent écrire et tester un parseur. Un logiciel qui contient son propre parseur de fichier non-trivial, à mon avis, c'est déja un signe que quelque chose ne tourne pas rond : soit tu a redéfini ton propre format (évidemment, sans norme ou doc sérieuse, ce qui fait que tes utilisateurs se trouvent à la merci de bogues aléatoires à l'utilisation de caractères spéciaux, d'encodage de fin de ligne différent, etc), soit tu as réimplémenté un parseur pour un format existant, ce qui est un bon exercice pendant ses études, mais qui relève de l'enc* de mouches dans le monde réel, puisqu'il est très très très très probable que quelqu'un d'autre l'a déja fait en mieux et libéré son code sous une licence assez permissive pour que tu puisses le réutiliser.

On n'a pas besoin d'épiloguer sur les défauts d'XML, tout le monde les connait. Quelques points qui vont dans l'autre sens quand même:
* La taille du fichier, on s'en fout pas mal, ça passe très très bien à la compression (c'est du texte très redondant)
* "Les devs ont la flemme d'écrire un parseur" -> "les devs ont l'intelligence de réutiliser des parseurs déja déboggués"
* La structure hiérarchique imposée par le xml permet de rationnaliser le stockage des données, à définir des noms de champs signifiants, etc.
* Il ne faut pas oublier la possibilité hyper-intéressante de définir un doctype et donc d'avoir une autovalidation du format, voire une auto-documentation.
* XML est conçu pour faciliter dans une grande mesure la compatibilité entre versions du fichier (en tout cas, ça ne va pas faire planter le parseur, ce qui est déja pas mal)
* Les gens qui ont un cerveau cablé d'une manière particulière qui permet de comprendre comment on se sert des moulinettes XSLT semblent trouver ça utile.

Je me demande au final si les problèmes attribués au XML ne sont pas en fait des problèmes à attribuer aux développeurs, qui utilisent XML à la place de fichiers textes, à la place de formats binaires (typiquement, pour stocker l'état interne d'un programme OO), ou à la place de bases de données. J'ai l'impression qu'XML excelle dans les formats qui mélangent contenant et contenu, avec une organisation peu prévisible—typiquement, des fichiers comme des pages HTML ou des documents de traitement de texte, où on va trouver des trucs comme <document> <title> Bla bla</title> Texte text <italics> texte texte </italics> <img url=http://www.image.com /> </document> . Une niche pas si large, mais dans laquelle les propriétés d'XML sont probablement beaucoup plus utiles qu'ailleurs.

Ce cas était très, très, très bizarre. Une bagnole est conçue pour s'arrêter dans tous les cas, il y a de multiples sécurités pour vérifier ça. Dans le cas très improbable où le régulateur de vitesse se bloquerait à 200 km/h, combien de temps mettrait une personne normale à 1) se mettre debout sur les freins (ce qui arrête toujours la bagnole, même avec l'accélérateur bloqué à fond, et même avec l'assistance au freinage désactivée), 2) mettre le frein à main, 3) rétrograder (à fond en première, tu ne roules pas à 200!), 4) mettre au point mort, 5) couper le contact ?

Le plus probable c'est que le gars a paniqué après avoir eu l'impression de s'être fait chopper pour excès de vitesse, et qu'il a inventé une histoire à dormir debout pour échapper à la prune.

issue.fr est en vente, et issue.uk n'est pas attribué. Ça ne semble pas être l'exemple parfait non plus…

Si on avait pas le DNS il faudrait que chaque internaute ait son propre annuaire pour trouver une IP pour aller sur un site…

Je n'ai jamais dit que le DNS n'était pas utile, ce que je dis c'est que la solution technique d'avoir mis en place des TLD concurrents était stupide, dangereuse, et motivée par l'appat du gain.

En gros, tu as 1) un système de nommage signifiant (très bien), 2) un système de répartition de la charge, sur des bases locales mais pas seulement (pourquoi pas?). Et là, on combine les deux, et c'est la merde totale. Un peu comme si tu partageais la charge sur plusieurs serveur de cache, mais que cache1/page1 te renvoyait quelque chose de différent de cache2/page1, en fonction de la localisation du serveur de cache et surtout de qui a payé plus cher l'hébergeur du serveur… hyper classe.

Donc à quoi sert le TLD ? Si quelqu'un réserve prout.fr et que je ne peux donc pas réserver prout.com ou prout.tv, etc… Autant dire qu'on a réservé prout, plus besoin de TLD…

Tu l'as dit toi-même plus haut : en pratique, la multi-réservation sert à (i) se préserver du cybersquattage et/ou des concurrents homonymes, et (ii) de faire une redirection vers un site dans une langue ou vers une filiale locale.

C'est pas parce que tu me sors plusieurs exemples que ton propos en est plus vrai. Je peux te répondre la même chose : ouai super des exemples qui posent problèmes pour des millions d'exemples qui fonctionnent.

Sauf que moi j'ai cité des vrais exemples qui posent des vrais problèmes dans la vraie vie, alors qu'en réponse je n'ai que des trucs théoriques qui n'existent pas. Non, sans blaguer :

• Le nom de domaine est un nom commun, type oiseau.fr ou botany.uk . Le risque de collision entre deux langues est ridiculement petit (faux amis parfaits), et ne justifie absolument pas une telle usine à gaz pour être géré. Par ailleurs, le fonctionnement d'internet montre que très peu de sites non-commerciaux, purement informatifs, existent—quand ils existent, ils sont hébergés avec une adresse en free.fr/oiseau. Personne ne tape une telle url au pif, d'ailleurs.
• Le nom de domaine est un nom de famille, pour un usage privé. Les homonymes dans un pays sont légion, et la gestion des homonymies internationales est hyper-marginal, puisque même à l'heure de la mondialisation, il ne risque pas trop d'y avoir beaucoup de concurrence sur martin.jp .
• Le nom de domaine est le nom d'une petite entreprise locale, qui n'est pas destinée à faire de l'international. J'imagine que c'est sur ce genre de cas que le TDL est censé être motivé. Le problème est qu'Internet est international par défaut, et que la résolution à l'échelle d'un pays ne fonctionne pas—s'il y a des toto-taxi.fr vs taxi-toto.fr, je ne vois pas le gain pour toto-taxi.ca. D'ailleurs, la concurrence sur le domaine .com sera rude.
• Le nom de domaine est un nom de marque, d'organisation, ou d'association. Guerre totale, si deux ont le même nom, tout le monde va s'étriper sur les TLD nationaux en fonction de leur développement.

Non. Je peux retenir que FR c'est pour France, le site a des chances d'être en français, et COM c'est pas lié à un pays en particulier (même si dans ce cas, comme souvent, c'est le TLD pour les USA).

Transformer des indications de localisation en langue, c'est super débile, désolé. Pour avoir vécu à l'étranger dans un pays dont je ne connaissais pas la langue, j'ai maudit je ne sais pas combien de fois les crétins qui se permettaient d'imposer leur norme nombriliste par rapport aux préférences du navigateur. Taper "sncf.fr" ne veut pas dire que je parle français. Tu parles de sémantique des TLD, mais tu prouves que cette sémantique n'existe pas, c'est du petit bonheur la chance. Parfois, on est juste redirigé vers un serveur unique, parfois sur des serveurs locaux, parfois ça change la langue, parfois non, parfois le .com et le .fr redifigent vers l'entreprise et le service client local, mais parfois non. Personne n'utilise les TLD de la même manière, je pense que c'est le contraire d'un système sémantique.

… ce qui n'empêcherait pas d'avoir une base de données commune pour l'enregistrement de noms ; autrement dit, que le propriétaire de toto.fr puisse réserver toto.com et toto.be sans qu'un tiers ne puisse le faire. Ça permettrait de garder le système distribué tout en évitant le squattage local des TLD inutilisés.

Perso je surf google.com et google.fr, pour le fil d'actualité ou bien les recherches, et je fais bien la différence

Bah ouais, pareil que si c'était google.342 et google.129 . Le premier gusse qui a eu l'idée stupide de différencier des noms signifiants à partir d'une extension non signifiante(*) devrait être pendu par les parties génitales jusqu'à ce que mort s'ensuive. Je trouve ça dingue que des gens se soient tellement habitués au système qu'ils n'en voient même plus les failles!

(*) Il est peut-être possible qu'à l'origine, on ait pu imaginer que l'extension puisse être signifiante, mais elle ne l'est plus depuis très longtemps.

le protocole DNS est sensé justement gérer correctement les collisions

Ah ouais, vachement bien même : il les gère en rackettant les gens pour qu'ils payent très cher l'absence de collisions. Encore une fois, tartempion.com et tartempion.net qui ne renvoient pas au même site, c'est un superbe exemple de collision sémantique, gérée par DNS en ajoutant un truc sans signification après. Je ne vois pas où est l'élégance du système.

Centraliser les choses… fiou… S'il n'est pas possible de réserver le même nom sur deux TLD le TLD ne sert à rien :)

Mais si, c'est juste que quelqu'un d'autre ne pourrait pas réserver le même nom sur un autre TLD.

C'est un peu normal que tissue.uk et tissue.fr n'évoque pas la même chose à l'internaute !

Ouais, super, un exemple qui fonctionne censé faire oublier des millions d'exemples qui ne fonctionnent pas. C'est normal que pendant presque 10 ans, wikipedia.fr a été squattée et ne renvoyait pas sur fr.wikipedia.org ? C'est normal que sas.no, sas.se, et sas.dk renvoient vers le site de Scandinavian AirLines, mais que sas.de revoie vers le logiciel, et qu'il faille faire flysas.de pour les billets d'avion? Tu trouves normal qu'april.org renvoie vers l'association, alors que april.fr est une assurance? Faut arrêter de blamer les utilisateurs, les gens responsables d'Internet ont créé un système débile et corrompu sans aucun intérêt ni pour les internautes, ni pour les entreprises, simplement destiné à siphoner du pognon en entretenant un écosystème encourageant la concurrence féroce et l'escroquerie.

Les utilisateurs de Microsoft savent contourner les bugs de Windows, de la même manière dont on sait contourner les bugs d'Internet. Ni l'un ni l'autre ne devraient nous empêcher d'y voir les problèmes, les nier comme tu le fais en les faisant passer pour des fonctionnalités est un comportement d'utilisateur captif.

Sans compter que ça ne tient pas une seconde. La décision de créer des noms de domaines rend l'adresse signifiante : si on était restés aux adresses IP rentrées comme des numéros de téléphone, on n'aurait pas ce problème. À partir du moment où on a un système qui transforme une adresse numérique en suite de lettres (enfin l'inverse, mais vous voyez ce que je veux dire), on est en droit de s'attendre à ce que la suite de lettre ait une signification. Or, qu'est-ce que les gens lisent dans www.google.fr? Ils lisent "google". Ils ne lisent pas ".fr", car cette partie de l'adresse n'est pas signifiante, c'est une sorte de résidu technique de l'adessage, un peu comme si un numéro de téléphone pouvait s'écrire 04MarcelDupont.

L'argument de l'utilisateur un peu bête pourrait tenir s'il s'agissait de gérer les erreurs d'URL. Si quand on tapait www.google.fr ça renvoyait une erreur, on s'habituerait très vite à essayer quelques combinaisons .com .org .net pour trouver la bonne (c'est ce que je fais avec linuxfr, je ne me rappelle jamais de l'extension à la c***). Le problème c'est toutes les tentatives d'hameçonnage et d'escroquerie, qui font pointer des URL légitimes vers des sites pourris.

Après, qu'on ne s'étonne pas que les gens utilisent google comme serveur DNS (d'ailleurs, c'est ce que je fais de plus en plus). Gooogle a le bon gout de t'envoyer la plupart du temps sur le site légitime, sans que tu ne tapes d'extension. C'est une sorte d'heuristique pour contourner les problèmes techniques graves générés par ce système idiot. Pourtant, il y aurait une solution simple : 1) supprimer les noms de domaine de moins de 4 caractères (on est sûrs et certains que les acronymes de 3 lettres vont entrer en collision), et 2) centraliser les choses pour qu'il ne soit pas possible de réserver le même nom sur des TLD différents. Évidemment, il y a le mythe du Marcel Dupont québécois qui serait grillé par le Marcel Dupont français, mais c'est peanuts par rapport à Marcel Dupont international qui ne peut pas réserver son nom au Canada parce qu'un couillon a créé un nom de domaine pour rediriger ses emails. La réservation du même nom avec des extentions différentes me semble être un bug, pas une feature du système.

Je suis exactement dans le même état d'esprit. Les ingé réseau sont habitués aux TLD, à la résolution des noms de domaines, au problèmes techniques liés aux DNS, etc. Mais vu de l'extérieur, ces trucs paraissent complètement ridicules, et vont dans le sens opposé à ce qui serait logique : plus on a TLD et plus on a de caractères spéciaux, plus les risques de squattage et d'hameçonnage sont importants. J'ai l'impression que les décisions récentes sont faites uniquement pour enrichir l'ICANN et les gestionnaires de noms de domaines ; en side effect ça va enrichir les escrocs; et au final c'est l'économie réelle qui va être ponctionnée.

Rien que pour Wikipédia, les noms de domaine représentent un budget très conséquent, avec des milliers de noms à réserver. Je trouve ça anormal qu'une association doive dépenser des dizaines de milliers de dollars tous les ans pour éviter que des escrocs squattent wikipedia.to, wikiqedia.fr, ou tout un tas de combinaisons unicode invisibles à l'œil nu. À chaque fois qu'un nouveau TLD apparait, paf, encore des centaines de dollars de claqués pour absolument rien.

Ajouter des overload n'est pas compatible source.

Ah oui, moi j'étais juste resté sur les problèmes de cast automatique (style void func(double) qui peut être appelée func(3) ou func(3.0) sans problème, jusqu'au jour où elle est overloadée en void func(int)), qui ne posent problème que si le code est crade.

Je ne connais rien aux contraintes des compilos et des problèmes de cohérence des langages, mais il ne serait pas plus sain d'avoir un mot clé, je ne sais pas «nooverload», pour justement garantir à l'utilisateur que l'API est stable en terme d'overload, et qu'il peut faire des pointeurs de fonction de manière stable?

la trouvez vous utile et esthétique?

Avec une URL qui ne fonctionne pas, a priori, je ne saurais pas vous répondre. En général, les application n'offrent aucune plus-value aux utilisateurs par rapport à un site web bien fait. Donc sans voir l'appli, je dirais que non, elle n'apporte rien. Faites un site web accessible, ça suffit.

Au passage, je ne voulais pas paraitre impoli dans mon message précédent, mais les gens qui participent à ce site sont en moyenne assez spécialisés, et sensibilisés aux problèmes de respect de la vie privée, et de l'accès au code des logiciels qu'ils utilisent. Votre question est visiblement complètement naïve, et probablement sans le savoir, vous faites de la promotion pour quelque chose que la plupart d'entre nous détestons : une application propriétaire, qui n'apporte rien, qui n'est pas accessible (la preuve, nous ne pouvons rien voir de nos ordinateurs), et dont le seul objectif est peut-être de récupérer des données privées sur les téléphones de vos clients (géolocalisation, etc). Vous ne pouvez pas vous attendre à ce que les gens y mettent les formes si vous ne prenez pas 30 secondes pour comprendre où vous posez vos questions…

Mais ça ne marche pas car attemptMessage est overloadé et donc il faut faire un case explicite vers le bon type pour résoudre quelle overload on prend

Huhu, ça veut dire que le fait d'overloader une function quelque part peut péter le code à l'endroit qui appelle la fonction quand on utilise bind? Ça ressemble à un argument très fort contre l'utilisation de bind, non? Comment peut-on savoir a priori si la fonction qu'on bind est overloadée ou pas, et si on a la garantie qu'elle ne le sera jamais? Si je n'ai pas compris de travers,

auto fun_prt = &externalfunc;
auto f = bind(fun_prt, 3);

peut marcher pendant des années, jusqu'au jour ou quelqu'un overloadera externalfunc? Ça me semble super bugogène ce truc, non?

Euh, je ne comprends pas : c'est une tentative d'escroquerie / virus / cheval de Troie (chez moi l'URL codée par le QR code renvoie une erreur, mais peut-être que d'un mobile ça fait quelque chose), ou la personne qui a posté ce fil est simplement numériquement illétrée?

Je n'ai pas assez d'expérience en C++ pour savoir si le code cité est un exemple de «ceinture noire C++ 18ème dan», ou bien de l'obfuscation. On a quand même, en trois lignes de code,

1) Un pointeur de fonction interne overloadée et polymorphe, qui prend pour argument une ref constante, un pointeur, et une ref non constante, le tout vers des classes maisons—au passage, est-ce que la fonction attemptMessage est statique?
2) un appel à la fonction "repeatedly" avec de la STL hardcore, avec au passage l'argument MailStoreReadLock& que je ne vois pas (peut-être est-il fourni par défaut dans QMailStore::attemptMessage?)

Est-ce ce qu'il n'est vraiment pas spossible de faire tout ça plus simplement?

Vim est très gros, maintenir un fork de cette taille est un boulot monstrueux

Justement, Vim est très gros, mais est-ce que ce n'est pas le principal problème? Visiblement, il faut avoir le cœur bien accroché pour aller voir le code, on dirait les avertissements vers les liens des vidéos de terroristes qui égorgent leurs otages à la machette rouillée. Donc j'avoue ne pas être assez courageux pour aller zyeuter les entrailles de vim, mais vu de l'extérieur, il n'est probablement pas nécessaire d'avoir des centaines de milliers de lignes de code pour un éditeur de texte de cette nature. Si le fork se concentre sur un système de plug-ins, il sera peut-être possible d'avoir une base saine minimaliste autour de laquelle pourront se greffer des extensions qui n'auront pas à être maintenues par le projet cœur. Enfin c'est ce que j'ai cru comprendre, vu de loin.

Bah je ne sais pas, "pour participer au développement de son projet open source et à sa mise en oeuvre dans le cadre de projets clients" paraît un peu louche quand même, non? Ça ne ressemble pas vraiment à un mini-projet qui peut échouer si l'étudiant est un peu naze, ça ressemble plutôt à un projet bien concret dans lequel le stagiaire aura des tâches à effectuer, et quelque chose à fournir à la fin.

D'une manière générale, je n'aime pas trop ces posts de blogs «le monde entier est rempli de cons, spécialement les instances décisionnaires, alors que je suis un Dieu et que j'ai la science infuse». J'imagine que les décisions au sein d'un comité de standardisation ne sont pas prises au hasard, elles sont le résultat de débats techniques et politiques, souvent d'ailleurs sous forme de compromis entre plusieurs visions irréconciliables.

Au passage, j'ai beaucoup de mal à comprendre comment HTTP2 pourrait casser le web, comme l'auteur du post le sous-entend. Au pire du pire du pire, le navigateur risque de renvoyer une erreur explicite au lieu de rediriger vers la bonne URL (et dans la plupart des cas, le comportement du navigateur sera conforme). J'ai un peu l'impression qu'il y a des sujets plus graves dans la vie que la normalisation pas carrée des erreurs 301 et 302…

À ce que je sache, le critère de monotonie n'est absolument pas lié au principe de la démocratie. Il ne faut pas tout confondre.

Pour toi, le populisme est le parti du peuple? :-@ Entre ton pseudo et ce que tu racontes, j'ai l'impression que tu es parti dans une sorte d'heuristique politique basée sur la logique floue, et que tu espères que tes interlocuteurs arrivent à en tirer quelque chose de cohérent—ça n'est pas gagné.

Je ne connais pas un seul système qui fonctionne sur la base d'un partage collégial des responsabilités. Si tu veux qu'un bus arrive à bon port, il faut que les passagers soient d'accord sur la destination, et qu'il y ait un seul chauffeur. Si tout le monde conduit le bus en même temps, ça ne va pas. C'est pareil au boulot, c'est pareil à la maison, c'est pareil à l'école, c'est pareil au foot, c'est pareil partout. Mais ça n'est pas intuitif : quand on arrive au lycée en seconde et qu'il faut faire des exposés en groupe avec les copains, on se le fait collégial : youpi, on va tous travailler ensemble sur l'exposé. Et c'est la cata, évidemment, car on n'a pas distribué les responsabilités. Dans la vie démocratique d'un pays, c'est exactement pareil. Quand on laisse tout le monde conduire le bus en même temps, comme ça serait le cas s'il y avait par exemple un référendum sur tous les projets de lois, on tournerait en rond, complètement au hasard. Le meilleur exemple, par exemple, c'est la peine de mort. D'une part, des élus représentatifs ont permis de faire gagner 15 ans à la France; mais en plus, si on avait laissé les lois évoluer au fil de l'opinion publique, on aurait rétabli ou aboli la peine de mort plusieurs fois par an!

Je pense que ça n'est pas du tout totalitaire de considérer que le peuple a le droit et le devoir de décider des options politiques, économiques, et sociétales prises dans une démocratie, et d'admettre que l'opinion publique n'a ni les capacités ni la légitimité pour gouverner un pays—pas plus que dans une SCOP les ouvriers n'ont pas la légitimité de diriger l'entreprise.

Knoppix 7.2 c'est un kernel 3.9.6 en version 32 bits par défaut, si je comprend bien les release notes.

De toutes manières, je ne vois pas comment on peut aider : tu dis "j'en ai essayé plein, ça ne marche pas" "lesquelles?" "Plein je vous dis!, tellement que je ne compte pas" "oui, mais quelles distribs, quels kernels?" "plein, mais là ça marche avec Knoppix".

Désolé, mais je ne le trouve pas démocratique.

Tu as le droit d'avoir l'avis que tu veux, mais ce qui est affirmé sans preuve peut être nié sans preuve. À partir du moment où on vote et que le vote a la possibilité de changer les élus, je ne vois pas comment on peut nier le caractère démocratique de la France. Je veux dire, à force de pousser le trait, tu finis par affirmer que nous ne vivons pas dans un régime démocratique, ce qui est objectivement faux.

On est un des rares pays a avoir ce système, il y a plein d'autres pays démocratique.

D'après [http://en.wikipedia.org/wiki/Table_of_voting_systems_by_nation], pour les assemblées, les systèmes "Winner-takes-it-all" (à un ou deux tours) sont largement majoritaires.

Il y a aussi plein d'autre manière d'envisager la démocratie, par exemple avoir des recours plus régulier au référendum.

Ça coûte cher et ça peut entrainer des votes populistes et démagogiques, comme en Suisse. L'idée que la démocratie représentative serait une "fausse" démocratie est fallacieuse et naïve, ce n'est pas une voie très intéressante à suivre.