A-t-on une idée de l'impact concret des économies d'énergie apportées sur processeurs et GPU Intel ? Genre un benchmark de l'autonomie sur batterie dans certaines conditions…
"Panneau d'affichage" semble la traduction littérale de "display panel", cependant cette expression n'est guère utilisée en français. Pourquoi pas simplement "écran" ?
Ou alors, pour une solution portable sous Linux, OS X et Windows, il y a conda (avec conda-forge pour la construction de paquets et anaconda.org pour leur hébergement).
On est dans le psychologique sur la réaction des résidence principale.
Tout à fait. L'immobilier résidentiel est devenu une sorte de sujet religieux en France, sous la pression des divers discours politiques ("100% de propriétaires" ! évidemment pour arriver à cela il aurait fallu commencer par ne plus subventionner l'investissement locatif…) ou commerciaux (les acteurs de l'immobilier profitent bien de cette irrationalité et l'alimentent par leurs déclarations).
À moins que tu penses à autre chose, il s'agit juste du mécanisme normal de récupération de la TVA, pas d'une "détaxe" (la TVA est un jeu à somme nulle entre entreprises). Une entreprise récupère la TVA qu'elle a payée sur ses achats, et reverse la TVA qu'elle a collectée sur ses ventes.
En prenant 15%/90%, on produit au minimum 6 fois plus de chaleur avec les techniques moderne qu'ils n'en produisaient il y a quelques siècles. On pourrait donc chauffer six fois plus de foyers pour la même quantité de bois…
Ce calcul considère que les attentes sont les mêmes aujourd'hui et au 14è siècle. Or personne aujourd'hui ne veut revenir au confort médiéval, y compris question températures à l'intérieur des habitations en plein hiver.
C'est d'ailleurs égoïste de ne pas vouloir partager une part de richesse et du travail au reste du monde. Et attendre que leur droit de travail soit parfait pour commencer à l'envisager me paraît être très hypocrite en plus d'être irréaliste
Eh bien, j'espère que tu milites pour la délocalisation de ton propre travail, afin de pouvoir partager une part de richesse et du travail avec le reste du monde. Sinon, j'en déduirai que tu es aussi hypocrite et égoïste que les syndicalistes que tu critiques, puisque tu prêches la générosité chez les autres tout en te gardant bien de l'appliquer pour toi-même…
Les syndicalistes humanistes ? Mon cul, des égoïstes qui défendent uniquement le boulot de ceux qui en ont déjà et uniquement délimité à une partie ténue de la surface terrestre.
Cela reste plus admirable que d'insulter les gens au motif qu'ils n'ont pas les moyens de résoudre les problèmes de la Terre entière. Faut vraiment vivre chez les bisounours pour refuser toute action politique dès qu'elle a le simple pragmatisme de s'atteler à un problème localisé… On dirait une forme particulièrement infantile de catholicisme.
Quant à l'humanisme, c'est ici hors sujet : le propos des syndicats est de défendre les travailleurs salariés, pas de donner des leçons de morale. Contrairement à certains militants anti-syndicaux…
Elle justifie également une lutte des classes perpétuelle
Dire cela est un non-sens. La lutte des classes est un fait du monde social, de la même manière que l'attraction des corps est un fait du monde physique. Prétendre que le discours de Jaurès « justifie une lutte des classes perpétuelle » est du même tonneau que prétendre que Newton « justifiait une attraction des corps perpétuelle ». Jaurès sait simplement que tant que le salariat et le mode de production capitaliste existeront, la lutte des classes existera également, car elle est l'expression automatique des conflits d'intérêts entre classes : le capitaliste veut maximiser la plus-value qu'il prélève sur le travail des salariés, tandis que le salarié veut une amélioration de ses conditions qui implique une diminution de la dite plus-value…
comme si les ouvriers étaient incapables de s'organiser de manière efficace et de trouver également des moyens de pression "civilisés" pour une négociation d'égal à égal
Les ouvriers s'organisent au moyen de syndicats qui négocient, font entendre leurs revendications et, lorsque la situation les y incite (c'est-à-dire lorsque les moyens précédemment cités ont échoué), passent à l'action physique (grève, blocage, manifestation). Lorsque le rapport de force n'est pas trop défavorable, ce sont des moyens qui s'avèrent efficaces.
Les ouvriers eurent également un outil qui était le PCF, et qui fut jusqu'aux années 70 très efficace—malgré un grand légalisme—pour calmer les velléités des patrons et de leurs relais politiques.
Mais ces méthodes te déplaisent, tu as donc décrété qu'elles n'étaient pas "civilisées". Question argumentation, c'est à peu près vide, et ça revient à accuser son chien d'avoir la rage pour le tuer.
Quitte à mettre en avant des intellectuels de gauche, autant citer des économistes contemporains (pas certain que Piketti soit en odeur de sainteté chez les trotskystes, ceci dit), plutôt que de déterrer des fossiles qui sentent bon l'ère pré-Soviétique…
D'une part, Jaurès n'était pas troskyste (il aurait eu du mal à l'être…), d'autre part, la pertinence d'un discours ne dépend pas de son ancienneté. Piketty est un économiste compétent dans son domaine (l'étude de la fiscalité et des répartitions de patrimoine), mais son discours politique est indigent. Je ne pense pas qu'on trouvera chez Piketty le moindre questionnement sérieux, argumenté, sur la violence en politique, qui est ici le sujet… Contrairement à ce que pourrait laisser penser le discours assez monomaniaque de Piketty, on ne régule pas la violence sociale en déplaçant des curseurs et des taux d'imposition.
Quant à l'URSS, l'échec du "socialisme" soviétique n'a pas remis en cause l'existence de la lutte des classes en régime capitaliste, à ce que je sache.
PS : il vaut mieux éviter de fustiger les fossiles si c'est pour chanter ensuite les louanges d'un keynésien pur jus qui ne fait guère que réinventer l'eau tiède ; si Piketty a fait tant de bruit, c'est parce que la "pensée" économique dominante est parvenue à un tel niveau de nullité dogmatique que le simple fait d'exprimer des positions classiques dans les années 50 à 70 est vécu comme un exploit, une transgression formidable. Dans le même ordre d'idées, certains ont présenté Varoufakis comme une sorte de lost boy révolutionnaire au prétexte qu'il portait des blousons de cuir et qu'il prônait l'adjonction de quelques gouttes de keynésianisme à la politique économique de l'UE…
Ce discours est profondément débile. Il y a quantité d'industries où on ne lance pas sa petite entreprise avec le moindre espoir sérieux de faire son trou. Un ouvrier du nucléaire, de la pétrochimie ou de la sidérurgie, il fait quoi ? Il crée sa petite SARL pour faire concurrence aux multinationales du secteur ?
Faut vraiment vivre sur la Lune pour penser que la création de petites entreprises est une perspective crédible pour une part importante de la population, alors que depuis deux siècles le progrès technique rend les industries (*) de plus en plus gourmandes en capital et en concentration. Au mieux, on crée aujourd'hui de fausses entreprises, c'est-à-dire des quasi-salariés grimés en entrepreneurs individuels (cas de pas mal d'auto-entrepreneurs) ou bien des quasi-filiales sous la forme de fournisseurs (sous-traitants) vassalisés par leurs gros clients.
(*) (et quand je dis industries, c'est au sens large : par exemple le petit commerce est en perte de vitesse depuis des décennies face à la grande distribution)
Je réitère ma question. Tu as affirmé que le soi-disant symbole des hackers était "globalement auto-choisi". J'aimerais toujours une explication, car je ne vois pas quelle argumentation permet de parvenir à une telle conclusion.
ce sont "les hackers" (pas tous bien sûr, il y a toujours des exceptions) qui ont accepté ce symbole comme le leur.
Ah bon ? Et comment décides-tu que "les hackers" (c'est qui ?) ont "accepté" (selon quelle procédure ?) ce symbole ?
Je suis désolé, moi, on ne m'a jamais demandé mon avis quant à ce symbole. Maintenant, est-ce que je suis un "hacker" selon les quelques zozos qui voudraient nous faire gober ce symbole d'appartenance, je n'en sais rien : c'est toute la commodité des dénominations à la con genre "hacker", "geek", etc. : c'est tellement mal défini qu'on peut en exclure quiconque nous déplaît…
Des langages comme Python, Java ou C# progressent là où auparavant on n'utilisait que du C ou du C++ (ou Fortran), il est donc parfaitement justifié de dire que les langages à gestion automatique de la mémoire progressent par rapport à ceux à gestion manuelle de la mémoire.
Le coeur d'Unity est fait en C++. C# est utilisé pour le scripting des games mechanics.
Et alors ? C'est justement l'important : les milliers de programmeurs utilisant Unity écrivent en C# et n'ont pas à gérer la mémoire à la main.
Seul l'interface est en python.
Même réponse. On s'en fout qu'une partie du backend soit écrit en C/C++, lorsqu'on n'a pas soi-même à écrire du C/C++ ni à gérer la mémoire à la main. Les objets Numpy et Pandas sont bel et bien gérés par la même infrastructure que n'importe quel autre objet Python…
Bien évidemment. On ajoutera que le noyau et le compilateur Fortran sont codés en C (*), que dans Numpy il y a beaucoup de code C également, et que derrière tout cela il y a certainement aussi des lignes d'assembleur (peut-être même qu'à un moment des gens ont entré des octets à la main directement dans la mémoire—enfin, à l'aide d'un clavier tout de même, quoique).
Il reste que pour le programmeur utilisant Numpy, le langage exposé est Python, et la sémantique de gestion de la mémoire est aussi celle de Python, ce qui est un peu l'important ici.
(*) Ok, pour le compilateur Fortran, j'ai la flemme de vérifier ;-)
Tu fais une analogie clairement abusive entre gestion manuelle et bug.
À chaque fois que l'on peut faire assurer une tâche automatiquement par une infrastructure fiable et éprouvée (un GC, par exemple), on réduit l'intervention manuelle du programmeur et donc on réduit la probabilité de bugs. C'est aussi bête que ça.
(ce n'est pas une analogie, c'est un lien de causalité)
Les domaines pour lesquels un GC est inenvisageable à l'heure actuelle ne risque pas de diminuer parce que, pour la plupart, ce sont des domaines où les performances et/ou la latence sont primordiales
Les domaines où les performances sont suffisamment "primordiales" pour interdire l'utilisation d'un GC fondent comme neige au soleil. Aujourd'hui, de plus en plus de jeux vidéo sont écrits avec un langage à GC (les jeux écrits avec Unity 3D, par exemple). On fait du calcul scientifique en Python. Cassandra, Hadoop sont écrits en Java. Des services critiques tournent sous une VM Erlang. etc.
Ce que tu appelles «défaut», ou plus bas «problème», c'est-à-dire la gestion manuelle de la mémoire,
Non, ce que j'appelle défaut, c'est un bug, une fuite mémoire, un crash, un trou de sécu, etc.
et tu as une manière très condescendante d'expliquer qu'on est tous des gros débiles à vouloir gérer manuellement la mémoire
Ma condescendance répond au complexe de supériorité des gens qui pensent que les défauts de gestion mémoire sont forcément dus à l'intervention d'un "mauvais programmeur"…
Postuler des turpitudes individuelles comme cause de tous les problèmes empêche de prendre conscience des effets de système. La difficulté de la gestion manuelle de la mémoire dans une application complexe, par exemple, est un effet de système inévitable (car les logiciels ne reviendront pas à la complexité des années 60, au contraire). L'historique complexe de l'évolution des projets sur de longues périodes est un autre effet de système (ce qui conduit par exemple à une discordance des conventions internes et d'éventuels malentendus sur icelles).
Évidemment, tout reporter sur les "mauvais programmeurs" est d'autant plus facile que la notion est mal définie et chacun peut décider selon ses propres critères qui est un "mauvais programmeur" (ce qui rappelle un célèbre sketch des Inconnus). Et la désignation d'un bouc-émissaire produit un effet de catharsis assez plaisant chez beaucoup d'êtres humains.
C'est ce que font plein de gens tous les jours dans tous un tas de domaines où un GC est hors de question.
La proportion d'applications où un GC est hors de question est appelée à diminuer. Comme le rappelle un intervenant, un téléphone "intelligent" aujourd'hui est suffisamment puissant pour faire tourner une JVM entière.
Oui, dans mon souvenir le parcours n'est pas incrémental : il y a déjà eu des rapports de bugs concernant les pauses ?
Non, mais on a déjà vu par le passé des gens disant qu'ils désactivaient le GC pour raison de performances. Je crois que CCP (éditeur de Eve Online) le fait.
La "safety" d'un langage et sa gestion mémoire sont deux chose différentes.
Je ne parle pas de la sûreté d'un langage, mais de celle des applications écrites d'une certaine manière (avec un GC, ou sans, par exemple). Et au-delà de la sécurité, c'est un problème plus général de qualité logicielle qui se pose.
Rust est plus résistant aux buffer overflow que la plupart des langages des script
Rust est tellement jeune (et, pour l'instant, peu utilisé) que l'on n'a pas de recul sur les problèmes des applications écrites en Rust.
Tu peux d'ailleurs faire un buffer overflow ou créer une faille de sécurité en C sans même faire une seule allocation dynamique.
Les problèmes du C ne se limitent certes pas à la gestion manuelle de la mémoire. Mais la gestion manuelle de la mémoire fait cependant partie de ses problèmes, et la complexité de la tâche (sur des applications non-triviales) fait que c'est un facteur important de défauts.
Un bon GC est meilleure qu'un mauvais programmeur : ho la bonne surprise. Je vais te la faire à l'envers : un mauvais GC est pire qu'un bon programmeur ! Et on a bien fait avancer le bouzin.
Ce qui fait avancer le bouzin, c'est qu'il y a peu d'implémentations de GC par rapport au nombre de programmeurs, que les GC sont en général écrits par des gens pointus, et que vu le nombre d'utilisateurs et les ressources de développement qu'ils ont, ils sont souvent correctement débuggés et optimisés.
Bref, c'est l'avantage classique de mutualiser et déléguer le développement d'infrastructures critiques (gestion mémoire, routines d'E/S, ordonnancement de tâches, etc.) à des équipes hautement spécialisées dont le travail sera réutilisé par un grand nombre de gens. Quelle drôle d'idée !
Ensuite, rien n'empêche d'utiliser un allocateur spécifique pour ce cas là
Certes, rien n'empêche de tout réécrire à la main et de passer des jours à fignoler et débugger ce qui prendrait dix minutes dans un langage haut niveau. J'espère que tu appliques la même discipline en ce qui concerne ta libc, ta libm, tes primitives de synchronisation, ton noyau de système d'exploitation, etc.
(je ne parle pas du jour où il faudra que tes allocateurs spécifiques cohabitent harmonieusement avec des infrastructures tierces, par exemple un détecteur de fuites genre Valgrind—tiens, ça me rappelle une histoire avec OpenSSL)
Un programmeur correct sait faire ça assez vite
Mouarf. Soit les bibliothèques et applications C qui ont régulièrement des trous de sécu et des fuites mémoire sont écrites par des clampins (c'est quand même ballot, ça : ils auraient dû demander l'aide des gens comme toi), soit tu surestimes largement la protection contre les défauts qu'apportent des compétences en programmation bas niveau.
J'ai ma petite idée sur laquelle des deux explications est la bonne.
il se contente de collecter les cycles, donc ce qui n'est pas libéré par le comptage de référence. Donc en gros il ne va pas faire d'analyse du graphe d'objets et des piles, contrairement à des GCs comme on l'entend classiquement (Java, Go…) (je parle de cPython uniquement).
Ben… il parcourt quand même le graphe d'objets pour détecter les cycles morts (la traversée du graphe se faisant via tp_traverse).
Les deux gros avantages sont :
comme cela ne sert que pour les cycles morts, on peut faire passer le GC beaucoup moins fréquemment puisque la majorité des références sont normalement relâchées par comptage de référence. Ceci dit, quand la génération la plus âgée est parcourue, ça peut prendre du temps.
certains objets, qui ne peuvent par construction appartenir à un cycle de référence, sont dispensés de ce parcours (par exemple les entiers, chaînes de caractères…)
Les algorithmes plus récents tentent de réduire cette probabilité en étant plus malin et surtout en allongeant la taille du hash.
Ce n'est pas tant en allongeant la taille du hash qu'ils réduisent cette probabilité, mais en tirant des leçons des algorithmes précédents. Un hash de 160 bits est assez long si l'algorithme est sûr : si SHA1 est en phase de remplacement dans les applications de cryptographie, ce n'est pas parce que le hash est trop court mais parce que l'algo est désormais considéré comme vulnérable.
Le "pas mal" n'étant pas mesurable
Il serait idiot de prétendre que SHA256 produit pas mal de collisions si ce n'était pas mesurable. En réalité, si SHA256 est une fonction de hachage cryptographique parfaite, la probabilité de collisions est gouvernée par le paradoxe des anniversaires : elle est dans ce cas ridiculement faible.
C'est pourquoi l'idée d'ajouter des indicateurs pour réduire la probabilité de collisions liée à SHA256 est une affirmation qui, prise au sérieux, sous-entend que SHA256 serait cassé.
PS : à ma connaissance, pas une seule collision de SHA256 n'a été répertoriée pour l'instant…
Cette discussion montre bien à quel point IPv6 est plus difficilement compréhensible pour l'utilisateur final.
IPv4 : c'est simple, chaque interface a une adresse (par défaut), point. IPv6 : j'ai trois adresses différentes sur la même interface…
L'électricité d'origine nucléaire, telle que tarifée en ce moment, remplie parfaitement cette diminution du coût de l'énergie.
Oui… Elle fournit aussi une production régulière et pilotable (ce n'est pas le cas des renouvelables), émettant peu de gaz à effets de serre (ce n'est pas le cas de la combustion d'hydrocarbures), et une grande partie des dépenses alimente des entreprises françaises avec un savoir-faire pointu, plutôt que la rente pétrolière / gazière / charbonnière de pays étrangers.
Ça fait pas mal de vertus, en fait, même s'il y a aussi des défauts :-)
Il est clair cependant qu'il faudra payer plus cher à l'avenir, d'ailleurs cela fait quelques temps qu'EDF réclame une augmentation des tarifs, ce que les gouvernements refusent par démagogie (tout en encaissant de juteux dividendes sur les bénéfices d'EDF, faut pas déconner).
Mon flair me dit que le nucléaire n'a plus d'avenir depuis un certain temps déjà (la dette d'Areva qu'avale EDF sort pas de nulle part). À part quelques projets qui finiront probablement en fiasco jamais rentabilisé, tout semble tendre au gel dans ce secteur
Ce n'est pas évident. Il n'y a pas eu de grand projet nucléaire en France entre les années 80 et l'EPR, à ma connaissance. L'EPR est une tête de série. Si on continue, les exemplaires suivants devraient poser largement moins de problème (et donc coûter moins cher à construire).
Le gel dans ce secteur est aussi dû à une opposition vocale et très médiatique de groupes minoritaires mais déterminés (genre "Sortir du Nucléaire", ou bien sûr EELV). Il faut savoir que la majorité de la population française n'est nullement opposée à l'électricité nucléaire.
Areva a souffert d'une gestion hasardeuse et d'investissements foireux, je crois (ainsi que de batailles de pouvoir mortifères). Ce n'est pas l'activité nucléaire en elle-même qui n'est pas rentable…
Politiquement, la mode est aux renouvelables, car cela permet de réduire l'emprise du secteur public et de filer des activités stratégiques au secteur privé. Aujourd'hui les renouvelables (c'est-à-dire, en pratique, des acteurs privés motivés par le profit actionnarial) sont massivement subventionnés par la CSPE, une contribution payée par tous les usagers et qui permet de combler le déficit de rentabilité des renouvelables par rapport au nucléaire.
# Économies d'énergie
Posté par Antoine . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 6.
A-t-on une idée de l'impact concret des économies d'énergie apportées sur processeurs et GPU Intel ? Genre un benchmark de l'autonomie sur batterie dans certaines conditions…
# Panneau d'affichage
Posté par Antoine . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 7.
"Panneau d'affichage" semble la traduction littérale de "display panel", cependant cette expression n'est guère utilisée en français. Pourquoi pas simplement "écran" ?
[^] # Re: - pour les distributions
Posté par Antoine . En réponse à la dépêche Nextcloud, le fork d'ownCloud. Évalué à 2.
Ou alors, pour une solution portable sous Linux, OS X et Windows, il y a conda (avec conda-forge pour la construction de paquets et anaconda.org pour leur hébergement).
[^] # Re: Uber, Lebonrecel, Airbnb : pas de le l'économie collaborative
Posté par Antoine . En réponse au journal Le Bon Coin, Airbnb, Uber : Les prochaines poules aux œufs d'or. Évalué à 5.
Tout à fait. L'immobilier résidentiel est devenu une sorte de sujet religieux en France, sous la pression des divers discours politiques ("100% de propriétaires" ! évidemment pour arriver à cela il aurait fallu commencer par ne plus subventionner l'investissement locatif…) ou commerciaux (les acteurs de l'immobilier profitent bien de cette irrationalité et l'alimentent par leurs déclarations).
[^] # Re: Juste milieu ?
Posté par Antoine . En réponse au journal Le Bon Coin, Airbnb, Uber : Les prochaines poules aux œufs d'or. Évalué à 3.
À moins que tu penses à autre chose, il s'agit juste du mécanisme normal de récupération de la TVA, pas d'une "détaxe" (la TVA est un jeu à somme nulle entre entreprises). Une entreprise récupère la TVA qu'elle a payée sur ses achats, et reverse la TVA qu'elle a collectée sur ses ventes.
[^] # Re: Je soutiens Cellou Diallo
Posté par Antoine . En réponse à la dépêche Comité de soutien pour Cellou Diallo contre son expulsion. Évalué à 5.
Ce calcul considère que les attentes sont les mêmes aujourd'hui et au 14è siècle. Or personne aujourd'hui ne veut revenir au confort médiéval, y compris question températures à l'intérieur des habitations en plein hiver.
[^] # Re: Machine à noter
Posté par Antoine . En réponse au journal Quelle violence… ?. Évalué à 9.
Eh bien, j'espère que tu milites pour la délocalisation de ton propre travail, afin de pouvoir partager une part de richesse et du travail avec le reste du monde. Sinon, j'en déduirai que tu es aussi hypocrite et égoïste que les syndicalistes que tu critiques, puisque tu prêches la générosité chez les autres tout en te gardant bien de l'appliquer pour toi-même…
Cela reste plus admirable que d'insulter les gens au motif qu'ils n'ont pas les moyens de résoudre les problèmes de la Terre entière. Faut vraiment vivre chez les bisounours pour refuser toute action politique dès qu'elle a le simple pragmatisme de s'atteler à un problème localisé… On dirait une forme particulièrement infantile de catholicisme.
Quant à l'humanisme, c'est ici hors sujet : le propos des syndicats est de défendre les travailleurs salariés, pas de donner des leçons de morale. Contrairement à certains militants anti-syndicaux…
[^] # Re: Machine à noter
Posté par Antoine . En réponse au journal Quelle violence… ?. Évalué à 9.
Dire cela est un non-sens. La lutte des classes est un fait du monde social, de la même manière que l'attraction des corps est un fait du monde physique. Prétendre que le discours de Jaurès « justifie une lutte des classes perpétuelle » est du même tonneau que prétendre que Newton « justifiait une attraction des corps perpétuelle ». Jaurès sait simplement que tant que le salariat et le mode de production capitaliste existeront, la lutte des classes existera également, car elle est l'expression automatique des conflits d'intérêts entre classes : le capitaliste veut maximiser la plus-value qu'il prélève sur le travail des salariés, tandis que le salarié veut une amélioration de ses conditions qui implique une diminution de la dite plus-value…
Les ouvriers s'organisent au moyen de syndicats qui négocient, font entendre leurs revendications et, lorsque la situation les y incite (c'est-à-dire lorsque les moyens précédemment cités ont échoué), passent à l'action physique (grève, blocage, manifestation). Lorsque le rapport de force n'est pas trop défavorable, ce sont des moyens qui s'avèrent efficaces.
Les ouvriers eurent également un outil qui était le PCF, et qui fut jusqu'aux années 70 très efficace—malgré un grand légalisme—pour calmer les velléités des patrons et de leurs relais politiques.
Mais ces méthodes te déplaisent, tu as donc décrété qu'elles n'étaient pas "civilisées". Question argumentation, c'est à peu près vide, et ça revient à accuser son chien d'avoir la rage pour le tuer.
D'une part, Jaurès n'était pas troskyste (il aurait eu du mal à l'être…), d'autre part, la pertinence d'un discours ne dépend pas de son ancienneté. Piketty est un économiste compétent dans son domaine (l'étude de la fiscalité et des répartitions de patrimoine), mais son discours politique est indigent. Je ne pense pas qu'on trouvera chez Piketty le moindre questionnement sérieux, argumenté, sur la violence en politique, qui est ici le sujet… Contrairement à ce que pourrait laisser penser le discours assez monomaniaque de Piketty, on ne régule pas la violence sociale en déplaçant des curseurs et des taux d'imposition.
Quant à l'URSS, l'échec du "socialisme" soviétique n'a pas remis en cause l'existence de la lutte des classes en régime capitaliste, à ce que je sache.
PS : il vaut mieux éviter de fustiger les fossiles si c'est pour chanter ensuite les louanges d'un keynésien pur jus qui ne fait guère que réinventer l'eau tiède ; si Piketty a fait tant de bruit, c'est parce que la "pensée" économique dominante est parvenue à un tel niveau de nullité dogmatique que le simple fait d'exprimer des positions classiques dans les années 50 à 70 est vécu comme un exploit, une transgression formidable. Dans le même ordre d'idées, certains ont présenté Varoufakis comme une sorte de lost boy révolutionnaire au prétexte qu'il portait des blousons de cuir et qu'il prônait l'adjonction de quelques gouttes de keynésianisme à la politique économique de l'UE…
[^] # Re: Machine à noter
Posté par Antoine . En réponse au journal Quelle violence… ?. Évalué à 10.
Ce discours est profondément débile. Il y a quantité d'industries où on ne lance pas sa petite entreprise avec le moindre espoir sérieux de faire son trou. Un ouvrier du nucléaire, de la pétrochimie ou de la sidérurgie, il fait quoi ? Il crée sa petite SARL pour faire concurrence aux multinationales du secteur ?
Faut vraiment vivre sur la Lune pour penser que la création de petites entreprises est une perspective crédible pour une part importante de la population, alors que depuis deux siècles le progrès technique rend les industries (*) de plus en plus gourmandes en capital et en concentration. Au mieux, on crée aujourd'hui de fausses entreprises, c'est-à-dire des quasi-salariés grimés en entrepreneurs individuels (cas de pas mal d'auto-entrepreneurs) ou bien des quasi-filiales sous la forme de fournisseurs (sous-traitants) vassalisés par leurs gros clients.
(*) (et quand je dis industries, c'est au sens large : par exemple le petit commerce est en perte de vitesse depuis des décennies face à la grande distribution)
[^] # Re: Lundi commence bien
Posté par Antoine . En réponse au journal Votez pour que le symbole des hackers soit ajouté dans Font-Awesome. Évalué à 4. Dernière modification le 25 mai 2016 à 01:05.
Je réitère ma question. Tu as affirmé que le soi-disant symbole des hackers était "globalement auto-choisi". J'aimerais toujours une explication, car je ne vois pas quelle argumentation permet de parvenir à une telle conclusion.
[^] # Re: Lundi commence bien
Posté par Antoine . En réponse au journal Votez pour que le symbole des hackers soit ajouté dans Font-Awesome. Évalué à 6.
Ah bon ? Et comment décides-tu que "les hackers" (c'est qui ?) ont "accepté" (selon quelle procédure ?) ce symbole ?
Je suis désolé, moi, on ne m'a jamais demandé mon avis quant à ce symbole. Maintenant, est-ce que je suis un "hacker" selon les quelques zozos qui voudraient nous faire gober ce symbole d'appartenance, je n'en sais rien : c'est toute la commodité des dénominations à la con genre "hacker", "geek", etc. : c'est tellement mal défini qu'on peut en exclure quiconque nous déplaît…
[^] # Re: Destructeurs
Posté par Antoine . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 1.
Mouarf. C'est un monument de mauvaise foi, là…
Des langages comme Python, Java ou C# progressent là où auparavant on n'utilisait que du C ou du C++ (ou Fortran), il est donc parfaitement justifié de dire que les langages à gestion automatique de la mémoire progressent par rapport à ceux à gestion manuelle de la mémoire.
[^] # Re: Destructeurs
Posté par Antoine . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 1.
Et alors ? C'est justement l'important : les milliers de programmeurs utilisant Unity écrivent en C# et n'ont pas à gérer la mémoire à la main.
Même réponse. On s'en fout qu'une partie du backend soit écrit en C/C++, lorsqu'on n'a pas soi-même à écrire du C/C++ ni à gérer la mémoire à la main. Les objets Numpy et Pandas sont bel et bien gérés par la même infrastructure que n'importe quel autre objet Python…
[^] # Re: Destructeurs
Posté par Antoine . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
Bien évidemment. On ajoutera que le noyau et le compilateur Fortran sont codés en C (*), que dans Numpy il y a beaucoup de code C également, et que derrière tout cela il y a certainement aussi des lignes d'assembleur (peut-être même qu'à un moment des gens ont entré des octets à la main directement dans la mémoire—enfin, à l'aide d'un clavier tout de même, quoique).
Il reste que pour le programmeur utilisant Numpy, le langage exposé est Python, et la sémantique de gestion de la mémoire est aussi celle de Python, ce qui est un peu l'important ici.
(*) Ok, pour le compilateur Fortran, j'ai la flemme de vérifier ;-)
[^] # Re: Destructeurs
Posté par Antoine . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 6.
À chaque fois que l'on peut faire assurer une tâche automatiquement par une infrastructure fiable et éprouvée (un GC, par exemple), on réduit l'intervention manuelle du programmeur et donc on réduit la probabilité de bugs. C'est aussi bête que ça.
(ce n'est pas une analogie, c'est un lien de causalité)
Les domaines où les performances sont suffisamment "primordiales" pour interdire l'utilisation d'un GC fondent comme neige au soleil. Aujourd'hui, de plus en plus de jeux vidéo sont écrits avec un langage à GC (les jeux écrits avec Unity 3D, par exemple). On fait du calcul scientifique en Python. Cassandra, Hadoop sont écrits en Java. Des services critiques tournent sous une VM Erlang. etc.
[^] # Re: Destructeurs
Posté par Antoine . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 8.
Non, ce que j'appelle défaut, c'est un bug, une fuite mémoire, un crash, un trou de sécu, etc.
Ma condescendance répond au complexe de supériorité des gens qui pensent que les défauts de gestion mémoire sont forcément dus à l'intervention d'un "mauvais programmeur"…
Postuler des turpitudes individuelles comme cause de tous les problèmes empêche de prendre conscience des effets de système. La difficulté de la gestion manuelle de la mémoire dans une application complexe, par exemple, est un effet de système inévitable (car les logiciels ne reviendront pas à la complexité des années 60, au contraire). L'historique complexe de l'évolution des projets sur de longues périodes est un autre effet de système (ce qui conduit par exemple à une discordance des conventions internes et d'éventuels malentendus sur icelles).
Évidemment, tout reporter sur les "mauvais programmeurs" est d'autant plus facile que la notion est mal définie et chacun peut décider selon ses propres critères qui est un "mauvais programmeur" (ce qui rappelle un célèbre sketch des Inconnus). Et la désignation d'un bouc-émissaire produit un effet de catharsis assez plaisant chez beaucoup d'êtres humains.
La proportion d'applications où un GC est hors de question est appelée à diminuer. Comme le rappelle un intervenant, un téléphone "intelligent" aujourd'hui est suffisamment puissant pour faire tourner une JVM entière.
[^] # Re: Destructeurs
Posté par Antoine . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
Non, mais on a déjà vu par le passé des gens disant qu'ils désactivaient le GC pour raison de performances. Je crois que CCP (éditeur de Eve Online) le fait.
[^] # Re: Destructeurs
Posté par Antoine . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 6.
Je ne parle pas de la sûreté d'un langage, mais de celle des applications écrites d'une certaine manière (avec un GC, ou sans, par exemple). Et au-delà de la sécurité, c'est un problème plus général de qualité logicielle qui se pose.
Rust est tellement jeune (et, pour l'instant, peu utilisé) que l'on n'a pas de recul sur les problèmes des applications écrites en Rust.
Les problèmes du C ne se limitent certes pas à la gestion manuelle de la mémoire. Mais la gestion manuelle de la mémoire fait cependant partie de ses problèmes, et la complexité de la tâche (sur des applications non-triviales) fait que c'est un facteur important de défauts.
[^] # Re: Destructeurs
Posté par Antoine . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 10.
Ce qui fait avancer le bouzin, c'est qu'il y a peu d'implémentations de GC par rapport au nombre de programmeurs, que les GC sont en général écrits par des gens pointus, et que vu le nombre d'utilisateurs et les ressources de développement qu'ils ont, ils sont souvent correctement débuggés et optimisés.
Bref, c'est l'avantage classique de mutualiser et déléguer le développement d'infrastructures critiques (gestion mémoire, routines d'E/S, ordonnancement de tâches, etc.) à des équipes hautement spécialisées dont le travail sera réutilisé par un grand nombre de gens. Quelle drôle d'idée !
Certes, rien n'empêche de tout réécrire à la main et de passer des jours à fignoler et débugger ce qui prendrait dix minutes dans un langage haut niveau. J'espère que tu appliques la même discipline en ce qui concerne ta libc, ta libm, tes primitives de synchronisation, ton noyau de système d'exploitation, etc.
(je ne parle pas du jour où il faudra que tes allocateurs spécifiques cohabitent harmonieusement avec des infrastructures tierces, par exemple un détecteur de fuites genre Valgrind—tiens, ça me rappelle une histoire avec OpenSSL)
Mouarf. Soit les bibliothèques et applications C qui ont régulièrement des trous de sécu et des fuites mémoire sont écrites par des clampins (c'est quand même ballot, ça : ils auraient dû demander l'aide des gens comme toi), soit tu surestimes largement la protection contre les défauts qu'apportent des compétences en programmation bas niveau.
J'ai ma petite idée sur laquelle des deux explications est la bonne.
[^] # Re: Destructeurs
Posté par Antoine . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
Ben… il parcourt quand même le graphe d'objets pour détecter les cycles morts (la traversée du graphe se faisant via
tp_traverse).Les deux gros avantages sont :
comme cela ne sert que pour les cycles morts, on peut faire passer le GC beaucoup moins fréquemment puisque la majorité des références sont normalement relâchées par comptage de référence. Ceci dit, quand la génération la plus âgée est parcourue, ça peut prendre du temps.
certains objets, qui ne peuvent par construction appartenir à un cycle de référence, sont dispensés de ce parcours (par exemple les entiers, chaînes de caractères…)
[^] # Re: Collision
Posté par Antoine . En réponse au journal zpaq : backup incrémental avec déduplication . Évalué à 1.
Ce n'est pas tant en allongeant la taille du hash qu'ils réduisent cette probabilité, mais en tirant des leçons des algorithmes précédents. Un hash de 160 bits est assez long si l'algorithme est sûr : si SHA1 est en phase de remplacement dans les applications de cryptographie, ce n'est pas parce que le hash est trop court mais parce que l'algo est désormais considéré comme vulnérable.
Il serait idiot de prétendre que SHA256 produit pas mal de collisions si ce n'était pas mesurable. En réalité, si SHA256 est une fonction de hachage cryptographique parfaite, la probabilité de collisions est gouvernée par le paradoxe des anniversaires : elle est dans ce cas ridiculement faible.
C'est pourquoi l'idée d'ajouter des indicateurs pour réduire la probabilité de collisions liée à SHA256 est une affirmation qui, prise au sérieux, sous-entend que SHA256 serait cassé.
PS : à ma connaissance, pas une seule collision de SHA256 n'a été répertoriée pour l'instant…
[^] # Re: Collision
Posté par Antoine . En réponse au journal zpaq : backup incrémental avec déduplication . Évalué à 1.
Tu es en train de dire que par défaut SHA256 produit pas mal de collisions ?
[^] # Re: Contrôle des IPs internes
Posté par Antoine . En réponse au sondage Utilisez-vous IPv6 ?. Évalué à 3.
Cette discussion montre bien à quel point IPv6 est plus difficilement compréhensible pour l'utilisateur final.
IPv4 : c'est simple, chaque interface a une adresse (par défaut), point. IPv6 : j'ai trois adresses différentes sur la même interface…
[^] # Re: Bonus écologique, et puis quoi encore ?
Posté par Antoine . En réponse au journal Moto journal: Le nucléaire passera-t-il ?. Évalué à 4.
Oui… Elle fournit aussi une production régulière et pilotable (ce n'est pas le cas des renouvelables), émettant peu de gaz à effets de serre (ce n'est pas le cas de la combustion d'hydrocarbures), et une grande partie des dépenses alimente des entreprises françaises avec un savoir-faire pointu, plutôt que la rente pétrolière / gazière / charbonnière de pays étrangers.
Ça fait pas mal de vertus, en fait, même s'il y a aussi des défauts :-)
Il est clair cependant qu'il faudra payer plus cher à l'avenir, d'ailleurs cela fait quelques temps qu'EDF réclame une augmentation des tarifs, ce que les gouvernements refusent par démagogie (tout en encaissant de juteux dividendes sur les bénéfices d'EDF, faut pas déconner).
[^] # Re: Bonus écologique, et puis quoi encore ?
Posté par Antoine . En réponse au journal Moto journal: Le nucléaire passera-t-il ?. Évalué à 4. Dernière modification le 19 avril 2016 à 20:51.
Ce n'est pas évident. Il n'y a pas eu de grand projet nucléaire en France entre les années 80 et l'EPR, à ma connaissance. L'EPR est une tête de série. Si on continue, les exemplaires suivants devraient poser largement moins de problème (et donc coûter moins cher à construire).
Le gel dans ce secteur est aussi dû à une opposition vocale et très médiatique de groupes minoritaires mais déterminés (genre "Sortir du Nucléaire", ou bien sûr EELV). Il faut savoir que la majorité de la population française n'est nullement opposée à l'électricité nucléaire.
Areva a souffert d'une gestion hasardeuse et d'investissements foireux, je crois (ainsi que de batailles de pouvoir mortifères). Ce n'est pas l'activité nucléaire en elle-même qui n'est pas rentable…
Politiquement, la mode est aux renouvelables, car cela permet de réduire l'emprise du secteur public et de filer des activités stratégiques au secteur privé. Aujourd'hui les renouvelables (c'est-à-dire, en pratique, des acteurs privés motivés par le profit actionnarial) sont massivement subventionnés par la CSPE, une contribution payée par tous les usagers et qui permet de combler le déficit de rentabilité des renouvelables par rapport au nucléaire.
À propos de l'EPR, un rapport intéressant par des ingénieurs EDF, "fuité" par Médiapart (un média par ailleurs largement anti-nucléaire) :
https://www.scribd.com/doc/306481134/Hinkley-Point-pdf