N'oublions pas non plus un des intérêts de la vidéo par rapport au texte : tu peux consulter sans être concentré à 100% dessus, quand tu manges, quand tu fais des tâches ménagères fixes (repasser, faire à manger, etc.). La lecture demande quand même de se focaliser dessus.
On peut retourner la chose aussi, si j'utilise une application non GNOME sur GNOME, la cohérence est perdue aussi. Est-ce pour autant que je râle car les applications de KDE (ou VLC, ou Firefox, etc.) ne s'adaptent pas à ce qui se passe sur mon environnement préféré ? Non.
Par définition, tu ne peux pas obtenir une application cohérente avec KDE et GNOME en même temps. Ou alors au prix d'une conception très complexe car tu dois maintenir deux interfaces en même temps. Pas gagnée.
Car une cohérence, ce n'est pas juste un thème ou quelques boutons bien placés. C'est aussi l'intégration avec le système comme le menu global ou centraliser la sauvegarde des données comme les contacts de l'utilisateur. C'est aussi le choix des mots dans la traduction comme l'original qui est cohérent. Quand une application X utilise le mot favoris quand le logiciel Y utilise le mot marques pages, cela a une incidence sur l'expérience utilisateur. Puis tu as des petits détails un peu partout sur ce que doit être le look and feel d'une application selon la plateforme. Par exemple pour les formulaires, Qt dresse une liste des différents points de vue : Windows / macOS et KDE : http://doc.qt.io/qt-5/qformlayout.html#details
Des détails du genre tu en as partout. Si Qt / GTK+ par exemple font des efforts d'abstraction ils ne peuvent tout prendre en charge automatiquement car le développeur doit aussi prendre cela en charge lui même pour de nombreux sujets.
Et tu le vois, Firefox, LibreOffice, Steam ou Avast par exemple ne s'intègrent pas parfaitement dans aucun environnement d'exécution. Car c'est très très difficile à réaliser. Alors que les applications de Microsoft sont globalement cohérentes entre elles (quand elles ont été rafraîchies), de même pour GNOME, de même pour Apple, etc. Alors que sur chacun de ces environnement, utilise une application multiplateforme quelconque et tu es sûr que l'intégration ne sera pas parfaite.
D'autant plus que quand tu es multiplateforme, comme Libreoffice ou Firefox, un dilemme se pose. Vaut-il mieux être intégré dans l'environnement de l'utilisateur, quel qu'il soit ? Ce qui est un travail titanesque. Ou vaut-il mieux que l'apparence de l'application soit identique indépendamment de la plateforme sous-jacente ? Ce qui simplifie la vie de son utilisateur en cas d'utilisation du programme dans différents contextes. Ce n'est pas un choix si évident en fin de compte. Comme toujours il faut trouver le compromis acceptable.
Bref, je ne vois pas de raison de taper sur GNOME là dessus. GNOME a une vision propre de ce que doit être un logiciel GNOME en terme d'apparence et d'intégration. Tout est documenté, il y a des procédures pour établir tout cela et essayer que cela forme un ensemble cohérent. Et tu veux que dans le même temps ils abattent un travail énorme qu'aucun autre logiciel ne fait vraiment. Ni Microsoft, ni Apple, ni Google, ni Mozilla, ni KDE (car oui le logiciel de KDE sous GNOME ne s'adapte pas vraiment à son nouvel environnement non plus) ne font ça par exemple. Cela n'est pas un reproche très cohérent si tu veux mon avis. Ce qui est rigolo étant donné le sujet.
Mouais. Je trouve que justement GNOME est l'un des rares environnements libres qui cherche une cohérence de son interface tout en restant efficace et agréable à l’œil. Après cela ne plaît pas à tout le monde, c'est normal, mais cracher sur leurs efforts à ce sujet me paraît osé.
J'ai l'impression que par lisible tu veux dire "rapide à lire".
Non, je veux dire que je peux aussi facilement retrouver l'information qui m'intéresse comme le nom de la variable de l'élément itéré. Cette information n'est pas masquée par le bruit de l'imposant nom du type.
Par lisible, j’entends compréhensible, et ceci ne l'est pas, car si la définition de "conteneur" est 40 lignes plus haut ou si c'est lui même un "auto" machin, le code n'est PAS compréhensible. Même pas en rêve avec tes technos dites "modernes" et les bonnes pratiques de mamie.
Et pourtant en pratique cela fonctionne très bien. Déjà quand tu évites d'avoir des fonctions de 20 kilomètres de long et que tu as un environnement de travail efficace, ça pose de suite moins de problèmes théoriques. Je rappelle qu'en programmation une bonne pratique est d'avoir des portions de codes réutilisables, réduites (des fonctions donc courtes) au maximum ce qui implique peu de variables dans le même scope. Cela allège grandement ta charge de travail pour ta mémoire
Enfin c'est amusant, moi je m'en suis servi, comme d'autres, dans des projets conséquents sans soucis et toi tu juges apparemment sans t'en être servi dans un langage avec un typage fort. Je te propose de tester en pratique avant d'émettre des de telles positions.
Car bon, inférence de types = JavaScript = merde, on a vu mieux comme argumentation. Je ne suis pas fan du JavaScript, mais ses défauts ne sont pas liés à son inférence de type (ou disons que son inférence de types gêne car il est faiblement typé).
Je ne dis pas que le compilateur va se tromper, c'est le programmeur qui ne peux pas s'y retrouver (à moins que ta "bonne pratique" c'est frde nommer les variables/les paramètres en incluant le type.
Un bon nommage peut largement induire aussi le type de l'objet. Tu te doutes que "i" dans une boucle est un entier, que "it" dans le même cas est un itérateur, que "name" est une chaîne de caractères. Cela aide à la compréhension et évite de devoir se préoccuper du type exact.
Car bon, même avec le type explicite à la déclaration, si tu es à 40 lignes plus bas et que tu as un doute, tu dois revenir en arrière pour vérifier. Ce n'est pas mieux.
c'est casse gueule au possible et complètement inutile (et c'est pas parce que Rust le fait que c'est bien).
Dixit le gars qui n'a jamais expérimenté tout cela au quotidien. Amusant.
Sinon l'inférence de types est également nécessaire pour exploiter les lambdas anonymes. Mais là encore, je sens que c'est une fonctionnalité sans intérêt pour toi.
(notons au passage que les gros projets Javascript migrent vers Cleartype pour justement avoir du code "lisible" et plus robuste que la loterie à base de "let" et "var")
Tu comprendras quand que le soucis du JavaScript n'est pas l'inférence de types en lui même ?
Le soucis de JavaScript est d'être faiblement typé, avec inférence de types et une faible rigueur de comportements. C'est ce cocktail qui est explosif. Cela tombe bien, beaucoup de langages modernes ont l'inférence de types pour ses avantages, mais ont un typage fort et un comportement rigoureux pour éviter ses effets de bord. Preuve qu'on peut avoir tout cela en même temps sans soucis.
Car ce cocktail, c'est lui qui fait que ta fonction attend un paramètre d'un certain type, que finalement tu lui envoies une valeur d'un autre type et qu'une conversion implicite absurde est appliquée. Le tout au runtime histoire que cela se détecte qu'en vol. C'est vraiment cette combinaison qui rend la maintenance d'un code JavaScript délicat.
Avec l'inférence de types et un typage fort, cela n'arrive pas. Tu n'as pas le type explicité partout, mais en cas de conflit le compilateur te prévient et tu résous cela en corrigeant le bogue ou en créant une conversion explicite du type A vers B si cela a un sens. Donc en cas de refactorisation tu es gagnant, tu peux changer le type d'une variable (passer de int à long, améliorer le nom de ta classe) sans devoir tout ressaisir (il y aura un peu de travail évidemment mais moins). Et tu allèges considérablement le code d'informations qui sont essentiellement redondantes ce qui rend le code plus aéré et donc lisible.
Suffit de passer ce "var" magique à une API qui a des méthodes de même nom mais avec des arguments de types différents pour être sûr d'avoir du code Java du niveau d'un code javascript…
Je ne vois pas le rapport. Le problème de JavaScript ou de Python à ce niveau c'est que tu peux avoir une variable de type entier qui est passé à une fonction où le type attendu est une chaîne de caractères ou inversement.
Là tu parles d'un cas où l'inférence de type a retrouvé le type tout seul et a pu appeler une méthode qui est du bon type. Du coup il n'y a pas de comportement bizarres à prévoir. D'autant plus que le compilateur ne fait pas des divinations très poussées, cela reste souvent assez élémentaire.
Quand tu écris :
autoentier=0;autobooleen=false;autochaine="chaîne de caractère";autoclasse_complexe=copie_de_cette_classe;autoautre_classe_complexe=AutreClasseComplexe(entier,booleen);
Tu crois qu'il va comprendre quoi ? Ce sera évident le type résultant. Et c'est 90% des cas où l'inférence de type sera utilisé. Le compilateur ne va clairement pas se vautrer sur ça. Car quand ce n'est pas assez clair ce qu'il doit faire, il va râler.
Je ne parle même pas des problèmes de refactoring que cela implique.
Grâce au typage fort et à la simplicité de l'écriture, cela fonctionne mieux que sans. Testé et approuvé.
L'argument C++ et autre, je vois pas le rapport, en C++ on peut aussi se contenter de void** !
J'ai dis C++ moderne (donc C++11, 14 ou 17). Le C++ à la C avec des pointeurs nus et des casts implicites et compagnie cela ne se fait plus dans les projets modernes (ou ne devraient pas se faire). Bientôt tu vas me parler de Java 1 aussi ?
Note que Rust et OCaml sont eux irréprochables en terme d'inférence de type et de typage fort. Des langages de conception modernes n'ayant aucun historique à porter là dessus.
Tu m'explique comment tu arrives à mieux lire le type de toto pour savoir quoi en faire 3 lignes plus bas?
L'inférence de type est un outil, si tu trouves qu'à un moment c'est plus lisible d'être explicite, fais-le. Cela ne signifie pas que la fonctionnalité est mauvaise pour autant.
on parle de type, pas de nom de variable ou de paramètre, gagner quelques octets dans un code source n'apporte rien à moins d'avoir de sérieuses douleurs au doigts.
Je ne parle pas de gagner en temps de frappe, quoique. Mais un code peut avoir des types à rallonge. Du coup tu perds en lisibilité car ton code sera dense qui va noyer ce qui est réellement important.
L'exemple le plus connu est sans doute les itérateurs en C++. Je préfère mille fois lire ça :
Car oui tu peux rapidement avoir des noms complexes du genre, et je te passe le cas quand c'est un tuple, une map ou autre qui peuvent grossir la taille de la déclaration.
Si tu fais des fonctions courtes, que tes variables et méthodes sont bien nommées (bref, respecter les bonnes pratiques) tu es largement gagnant à utiliser l'inférence de type. C'est comme râler sur les templates, lambda, etc. en pointant sur un cas de mauvaise utilisation. Alors que pourtant ils sont utiles aussi. C'est comme tout, faut pas en abuser mais on n'a aps à s'en priver.
C'est surtout aussi inutile que casse gueule… le typage fort c'est un avantage pas un inconvénient.
L'inférence de type n'a rien à voir avec typage fort ou non.
L'inférence de type est utilisé en C++ moderne, OCaml ou Rust par exemple alors qu'ils sont également fortement typés.
L'inférence de type signifie que le compilateur va déduire à partir du contexte le type de l'objet en question. S'il y arrive bien sûr. Une fois le type assigné à l'objet en interne, il va s'assurer que cela est cohérent avec le reste du programme. S'il y a conflit, une erreur va sauter à la compilation pour prévenir l'utilisateur que justement sa déclaration n'est pas bonne et qu'il doit le résoudre manuellement quelque part.
L'inférence de type permet surtout un code plus lisible et maintenable, en évitant les noms à rallonge de partout, qu'au moindre changement de nom tu aies une cascade de changements connexes à effectuer ou vérifier si ton éditeur t'aide. Et grâce au typage fort justement, tu as la garantie que les données sont correctement manipulées et représentées. Au moindre problème de ce côté, cela ne compilera de toute façon pas. Il n'y a rien de caché au programmeur.
Pourquoi ? Est-ce parce que le système d'init t'a empêché de le faire ? Ca m'est déjà arrivé de devoir forcer un reboot sous d'autres systemes, mais jamais parce que le système d'init en lui-même était tellement pourri qu'ill ne voulait pas le faire.
En fait comme SysV ne fait pas grand chose en tant que tel et que cela repose sur des scripts qui peuvent faire n'importe quoi, ton système peut être bloqué par un script d'init mal fait.
Donc oui, ce n'est pas init qui bloque, mais le design d'init SysV reposant sur la multitudes de scripts environnants pour faire son job (démarrer ou couper la machine), il faut en tenir compte dans l'évaluation.
Sinon faut être juste et ne pas compter les soucis avec dbus comme des problèmes liés à systemd…
BIIIP Contradiction détectée. Faut savoir : j'utilise ou j'utilise pas ? Si j'utilise pas, je ne rencontre pas de problème, non ?
Je n'ai pas dit que tu n'as pas utilisé systemd. Relis bien. J'ai dit que tu avais un avis négatif sur systemd avant même de t'en servir. Comme souvent dans cet état d'esprit, on monte en épingle le premier soucis rencontré sans relativiser son expérience par rapport à son propre passé avec une solution concurrente.
Le problème de systemd pour moi est qu'il multiplie les surcouches sur lesquelles il s'appuie pour pouvoir fonctionner.
Mais c'est bien d'avoir des couches. Le but de ces couches est de mutualiser le travail, ne pas réinventer la roue, avoir des composants plus solides.
systemd mutualise des tas de comportements. Et c'est très bien. L'init à la SysV c'est historique, c'est initialiser une machine à l'ancienne. C'était bien à l'époque mais le monde a évolué.
Bientôt tu vas rejeter les bibliothèques comme Qt, GTK+, Boost, glibc ou même le noyau car cela mutualise et ajoute des couches ? Réutiliser c'est l'essence même d'une bonne conception.
Et dès qu'il y a un grain de sable dans ces surcouches, on se tretrouve à ne pas pouvoir redémarrer sa machine
Oui un système plus complexe peut avoir plus de problèmes. Mais cela apporte plus de choses. cela n'a rien de spécifique à systemd et je ne vois pas en quoi cela est un soucis. Systemd a par design des tas d'avantages. Certes il y a des inconvénient, comme tout logiciel il y a des compromis de conception. C'est dommage mais un choix doit être fait.
Et bizarrement, il n'y a pas grand monde pour se bouger à maintenir les scripts init à l'ancienne, preuve que pas grande monde trouvait SysV si bien que cela à maintenir et à l'usage…
C'est un gros SPOF sur le système. Après on peut me dire que le noyau est aussi un SPOF, sauf que le noyau ne fait pas tout : il se contente de gérer les ressources hardware et délègue pas mal de choses aux couches supérieures.
Lol, systemd c'est pareil alors.
Le noyau Linux par sa conception fait beaucoup de choses. Suivant certaines conceptions comme micro-noyau, Linux fait vraiment trop de choses par lui même. Son cœur est trop gros. C'est un choix assumé par conception et l'histoire a montré que ce n'était pas absurde.
systemd, c'est exactement pareil, on peut faire autrement mais l'histoire montre que les choix opérés ont un sens et que le gain l'emporte sur les inconvénients.
Ce qui ne veut pas dire que cela n'est jamais arrivé à quiconque. Sous l'ère SysV, plusieurs fois j'ai du achever le redémarrage à la fin moi même.
Bref, tu utilises un cas personnel isolé (à priori ça t'es arrivé une fois, pas régulièrement) pour critiquer un projet que tu n'aimes pas avant même de t'en servir. C'est débile, c'est tout, que ce soit pour critiquer systemd, Firefox, Windows ou iTunes.
D'autant plus que oui, comparer SysV et systemd n'a pas forcément un grand sens sans tenir compte de tous les éléments. systemd est plus gros, peut donc avoir plus de bogues mais il apporte plein de fonctionnalités utiles que SysV ne propose pas et qu'il faut gérer manuellement (donc risque de bogues, peu de mutualisation, maintenance lourde), etc.
C'est comme critiquer Linux qui a plus de bogues que Minix ou GNOME qui consomme plus de mémoire que i3. C'est facile pour un petit projet de gagner dans ce genre de comparaisons, car ils ne font pas la moitié de ce que font les autres projets donc forcément quand tu ne fais pas grand chose, peu de chances de planter directement…
La corruption de données peut provenir de plein de facteurs différents, autant sur ARM, X32 ou X64. D’où les backups :)
Bien sûr, mais bon, c'est toi ici qui vient rapporter le fait que tu as eu un système down quelques temps probablement à cause de la carte SD.
On t'explique juste que la carte SD pour ce type d'usage ce n'est pas top, et pourquoi cela ne l'est pas. Après tu fais ce que tu veux.
Quelles problématiques as-tu (toi, pas lu sur internet) au quotidien ?
Merci mais je travaille dans le secteur quand même, je ne viens pas balancer des idées reçues sorties de nulle part.
Disons que dans le milieu comme je l'ai dit, si ton stockage principal est une carte SD ou eMMC, si tu ne veux pas serrer des fesses à chaque fois que ton appareil s'éteint de manière non propre, tu configures le tout pour minimiser le risque.
Si non, dans le cadre de serveurs prod, tout cela est loin d'être nécessaire : une carte SD a une durée de vie d'environ 2 ans
Tu n'as pas compris nos messages : la moindre coupure de courant dans ton montage actuel peut corrompre le contenu de la carte SD.
Après tu fais ce que tu veux.
(et pour les détracteurs des cartes SD, sur SSD c'est pas franchement plus stable)
Arrête ton char, si les mémoires flash (SSD inclus) ne sont pas d'une fiabilité parfaite (breaking news, aucun système de stockage n'est fiable à 100% en cas de coupure de courant prématurée) on est très loin des problématiques de la carte SD au quotidien.
D'autant plus que le bus USB est partagé avec le bus Ethernet. Donc pour un usage serveur cela introduit de la latence et une plus longue durée pour envoyer la réponse. En particulier pour un gros fichier par exemple.
En fait, tout ce qu'ils n'aiment pas ils le considèrent obsolète et répandent de la mésinformations.
Où est-ce qu'ils disent que KDE est obsolète et qu'ils dénigrent le projet ?
Les notes de version à ce sujet sont neutres, ils disent juste que le projet n'est plus pris en charge par le support de Red Hat.
deprecated ne signifie pas obsolète et n'a rien d'insultant.
Par contre les cartes SD sont de plus utilisées en domotique (par ex dans des chauffages central).
Les cartes SD peuvent être utilisées dans les systèmes embarqués mais pas n'importe comment. Sinon on obtient des pannes comme celle que tu viens d'avoir. Par ailleurs on privilégie les eMMC, assez proches en tant que tel mais plus robuste d'un point de vue électrique et mécanique en général.
Typiquement on limite au maximum les écritures (un maximum de boulot se fait en RAM, les écritures se font de manière régulières mais à des périodes définies). On désactive parfois le wear leveling, on interdit les cellules multi niveaux (enregistrer plusieurs bits dans une seule cellule). Le système d'exploitation est dans une partition en lecture seule, donc séparé des données à sauvegarder.
Bref, oui on trouve des cartes SD dans des systèmes embarqués. Mais cela ne s'improvise pas. Comme tu peux le voir, il y a des techniques à respecter pour que cela soit viable. Faire comme tu le fais serait une catastrophe potentielle à chaque coupure de l'appareil ce qui n'est pas acceptable en production.
Dans l’article que je cite il note bien que c’est sa propre grille d’analyse et explication qu’il propose en tout cas, il n’est pas si assertif que tu veux bien le dire.
Je cite le début de son article à ce sujet, seul moment de réserve de sa part :
L’Italie va mal. Ou plus exactement son PIB peine à retrouver de la croissance. C’est un des rares pays de l’OCDE qui n’arrive pas à se remettre de la « crise de 2008 », et dans le grand concert de tous ceux qui ont un avis sur la question je vous propose le mien, simplement basé… sur la physique.
Mouais, je trouve quand même que pour quelqu'un qui veut apporter un nouvel éclairage sur la question, il laisse trop d'éléments dans l'ombre pour que sa thèse soit réellement défendable. Et il prétend par là que son avis provient d'une analyse scientifique. Quand tu affirmes que tu bases ton analyse sur la physique pour donner du crédit à ton propos, tu insinues que ton raisonnement est scientifique. Il a les bases, mais très clairement ça manque de profondeur comme je l'ai souligné.
Perso je pense qu’un pays qui est peut être un peu plus faible que les autres pour des raisons structurelles soit celui qui trinque (plus que les autres) en cas de problème énergétique, n’est pas forcément idiot. Si la situation énergétique tend tout le monde, mais que les autres arrivent à s’en sortir parce qu’ils sont un poil plus robuste, un pays doit trinquer.
Oui mais non quand même. L'Italie a ses problèmes mais ce n'est pas non plus un pays incapable de faire du commerce mondial et incapable de payer plus cher des fournisseurs d'hydrocarbure pour alimenter son économie. En tout cas je pense que cette thèse qui est quand même assez fondamentale dans son explication mériterait une analyse complète pour expliquer en quoi c'est le cas. Car cela n'a vraiment rien d'évident.
Si ma grille de lecture est correcte, on peut s’attendre à ce que le « manque » d’énergie ne soit pas réparti de manière homogène sur tout les pays. Grosso modo, l’allemagne étant un très gros client risque de pouvoir s’approvisionner bien après que des pays plus petit aient bu la tasse en cas de grosse crise.
Je ne dis pas que cela n'arrivera pas dans un futur proche. Je suis convaincu que cela peut être le cas. Mais je ne suis pas convaincu que cela soit arrivé encore. Et encore moins que cela touche la 7-8e économie mondiale et pas un pays comme le Portugal par exemple.
j’avoue que j’ai un faible pour le côté complètement iconoclaste de ses thèses en matière d’analyse économique qui ne font que souligner que les économistes ne parlent que très très rarement de gestion des ressources, paradoxalement, alors que c’est une des bases de la discipline et qu’on les entend beaucoup dans les médias
Je trouve qu'en soit il apporte des pistes intéressantes, à creuser. Je ne renie pas cela. Cependant je fais très attention à ne pas prendre pour acquis ce genre de thèses tant que cela manque de rigueur dans l'analyse. Ce que certains font hélas.
Sur révolutions politiques et industrielles, je dirai rien parce que je dirai probablement des conneries, mais je pense qu’il n’est pas forcément simple d’isoler la date de la révolution industrielle (ex dans ce document ils parlent de « quelque part entre 1750 et 1850 »
La révolution industrielle n'a pas été un mouvement mondial spontané. C'est ce qui explique pourquoi il y a un siècle d'écart dans le document. Globalement on peut séparer en trois groupes :
Fin du XVIIIe : le Royaume-Uni, pays qui a amorcé le processus
Début du XIXe : Europe de l'Ouest riche de l'époque pas défoncés par les guerres napoléoniennes (France, Belgique, etc.)
Milieu du XIXe : le reste de l'Europe riche + USA
Tu noteras que globalement les trois démocraties que j'ai cité sont toujours nées avant les débuts de la révolution industrielle localement. Donc je persiste et je signe, la démocratie peut vivre sans une énergie abondante et peu chère. Cela peut aider les choses bien sûr dans ce processus mais il ne semble pas indispensable.
D'autant plus que ces dates approximatives sont le début du processus de la révolution industrielle dans chaque pays ou région, il faut un certain temps avant que cela ait un impact sur la population concret. Ce n'est pas avec une ligne de chemin de fer et une usine que tu changes drastiquement une vie nationale ! Il en faut un peu plus.
Les coûts sont également démocratiques (voire gratuits pour les demandeurs d’emploi).
Et cela fonctionne aussi pour les étrangers ! ;-)
Typiquement je suis des cours de néerlandais par ce biais depuis peu, 3h / semaine pour l'année scolaire complète revient à 68€ en tout. C'est en effet pas cher pour une formation.
On a rarement fait de l’analyse historique en se contentant de calcul :)
Non, mais une analyse historique mérite plus qu'une phrase balancée comme ça sans preuves.
D'autant plus que dans le cas britannique, américain et français il n'y avait à l'époque pas de machines à vapeur. Ce qui contrarie pour moi la thèse.
Tu notera qu’à l’époque des débuts de la démocratie en france la situation n’était pas totalement stable et qu’on a même connu un démocrate … empereur. Évidemment oxymore. Qu’est-ce qui a fait « tenir » la démocratie, système totalement soluble dans la dictature ?
La démocratie française a été tumultueuse au début oui. Mais les bases ont été jetées malgré tout. Tu noteras que la démocratie britannique et américaine ont été stables très tôt et bien avant la disponibilité de l'énergie pas chère en abondance.
Je ne dis pas après que ce qu'il dit est totalement absurde et est sans intérêt. Mais cela manque clairement de recul et d'analyse. Je me méfie donc de ses thèses sur le sujet car oui, cela reste douteux en l'état.
il a le mérite de faire une prédiction qui vaut sans doute bien des prévisions savantes d’économistes analysant les réformes structurelles aux conséquences parfois hasardeuses :)
Je ne dis pas que les économistes qui passent à la télé font mieux tu noteras.
Mais voilà, Jancovici veut adopter une méthode scientifique pour soutenir son propos. Et globalement il le fait bien. C'est justement ce qu'il me chagrine, c'est que parfois il tient des discours francs alors que la valeur scientifique de son propos est faible.
Clairement tu ne peux pas effacer son explication du PIB asservi à l’énergie dépensée pour la production d’un revers de main, je pense, surtout quand il montre la robustesse de cette corrélation en long en large et en travers sur de longues périodes. A la rigueur faudrait faire le chemin en sens inverse et montrer que les autres explications qu’on pourrait trouver sont aussi prédictives et fonctionnent aussi bien. On pourrait trouver qu’une fois corrigé des variations pétrolières, elles fonctionnent, ce qui montrerait que l’efficacité des solution traditionnelle des économiste est asservie à … la disponibilité de l’énergie.
Je ne dis pas que le lien PIB / énergie n'existe pas. Il est vrai, si demain tu supprimes l'approvisionnement d'énergie d'un pays, son PIB va chuter. En ce sens, je suis d'accord avec lui.
Mais le cas italien comme il l'a analysé a plusieurs soucis de raisonnement, qu'il ignore et n'explique pas. Or pour moi, ces éléments remettent en cause sa conclusion, au moins partiellement.
Je m'explique. L'économie est sans doute l'un des domaines les plus complexes à analyser. Car l'économie est influencée par des tas de facteurs : politique, éducation, sociologie, scientifique, géostratégie, l'histoire, etc. Débarquer en disant que la crise italienne provient d'un manque d'énergie en basant son raisonnement sur l'analyse de données qui concerne uniquement l'objet de sa thèse, ce n'est pas sérieux. Il faut analyser des tas de données, et montrer que seules les données allant dans le sens de sa thèse expliquent la situation avant de conclure. Sinon c'est un travail bâclé voire manipulatoire.
Car dans son article, il a montré une corrélation. Troublante, mais cela reste une corrélation. Une corrélation ne fait pas un lien de cause à effet. C'est pourquoi avant de conclure il doit analyser le reste, pour prouver le lien de cause à effet. Tout en essayant de se prémunir de certains biais comme le paradoxe de Simpson.
Bref, cet article n'est pas un travail de qualité. C'est digne d'un discours manipulatoire basé sur trois graphes pour aller dans le sens qu'il veut. Moi aussi avec deux graphes je te prouve que le réchauffement climatique n'est pas lié à l'Homme. Pourtant bizarrement, si je le fais, on m'en demandera (à raison) un peu plus avant de conclure. Jancovici semble touché par un phénomène répandu chez les experts, dès qu'on sort légèrement du domaine d'expertise (ici l'analyse du climat et le lien avec la consommation d'énergie), il essaye de tout expliquer à partir de son domaine d'expertise. Quitte à juste rassembler les éléments allant dans son sens mais ignorant le reste.
L'autre point gênant et pas des moindre qu'il n'explique pas. Pourquoi l'Italie est le seul pays riche, de l'OCDE tout ce qu'on veut qui manquerait d'énergie ? La 7e économie du monde aurait plus de mal à payer ses fournisseurs étrangers que des pays plus petits et moins riches comme le Portugal ? Cela ne me semble pas cohérent et logique. Du coup le manque d'explication à ce sujet serait même un indice que le problème italien est ailleurs qu'une difficulté d'approvisionnement en énergie. Et que la baisse de l'énergie consommée et du PIB serait due à autre chose.
Je n'aime pas non plus cette solution mais parfois elle s'impose.
Déjà comme je l'ai dis, avant de recourir à cette solution extrême, regarder du côté de logiciels et de distributions adaptées pour de vieilles configs de ce genre est je pense une bonne idée. Une distribution ne peut pas satisfaire tout le monde à la fois. Vouloir l'extrême nouveauté de chez Fedora tout en étant compatible sur de vieilles machines me semble illusoire.
Sinon, il est normal que de plus en plus de logiciels nécessitent (comme Firefox) d'instructions modernes du processeur. Pour des raisons de maintenances et de tests, c'est plus raisonnable (les ressources ne sont pas infinies côté humain aussi). Mais aussi, renoncer à utiliser du SSE2 alors que globalement quasiment tout le monde a un processeur compatible est un gâchis de ressources aussi. À quoi sert d'avoir du SSE2 dans le processeur si c'est pour ne jamais l'employer ?
D'autant plus que globalement de nombreux logiciels comme Firefox ne sont pas agréables au quotidien sur de vieilles machines. Le Web est devenu trop lourd avec le temps. Et pour naviguer sur des pages légères, il y a des navigateurs plus indiqués que Firefox pour cette tâche par exemple.
De toute façon on le voit que ces configs deviennent rares, rares au point que certains bogues très bloquants ne sont repérés que des mois ou années après l'introduction du problème. Car il n'y a plus assez d'utilisateurs dans la communauté pour tester, utiliser ou maintenir cette compatibilité.
Et comme le Logiciel Libre n'impose rien en tant que tel, si les gens utilisant des processeurs aussi anciens sont motivés, ils peuvent maintenir la compatibilité eux mêmes. Le soucis est que globalement les codeurs restent rarement aussi longtemps avec ce genre de machines. Et on ne peut pas les forcer à le faire.
Oui, tout ce que tu fais dans ton boulot doit être fait sous ton adresse pro. Et si ton adresse se perd, tant pis.
Par défaut tu as raison, dans l'absolu non. C'est à l'entreprise de décider quelle politique adopter à ce sujet. Elle peut accepter que cela se fasse avec une adresse courrielle perso mais avec la licence qui désigne l'entreprise.
Tout est possible, il faut en discuter avec l'entreprise ou ses responsables. C'est tout. Mais par défaut oui, l'adresse professionnelle doit être utilisée.
Effectivement le jeu d'instruction sse2 est apparu avec le Pentium 4 sorti en 2000 mais les prcesseurs AMD n'en ont été dotés que plus tard en 2003 avec l'Athlon 64 et à partir du modèle Paris du Sempron.
C'est vrai, mais malgré tout cela reste de vieux processeurs. Déjà l'image i686 est régulièrement menacée de disparition car les images x86_64 dominent largement (on est de l'ordre 95% d'accès aux dépôts pour les x86_64 pour 2-3% pour i686). Et encore certains utilisent des images i686 sur des processeurs compatibles x86_64.
Le soucis régulier est que Fedora ne marche pas toujours bien sur cette plateforme. Pendant des mois le noyau Linux n'était pas très opérationnel (mais c'était le cas en amont aussi). De nombreux logiciels abandonnent la maintenance ou les tests sur i686 ce qui n'est pas sans poser problèmes pour la maintenance. Donc même si Fedora faisait un effort, peu à peu le nombre d'applications compatibles baisse. Comme tu l'as mentionné, cela fait un moment que c'est le cas pour Firefox par exemple.
Je me suis replié sur Fedora 24 pour avoir une version de Firefox sans sse2 la 47, j'ai trouvé aussi en sse un binaire de la version 27 du navigateur Palemoon de 2016, qui gère mieux certains sites avec javascript.
Je te déconseille vivement d'utiliser Fedora sur cette machine (ou alors sans accès à Internet). Fedora 24 est assez ancien et la plupart des composants du système ont donc des failles de sécurité connues et non résolues.
Prends une distribution et des logiciels plus adaptés à ton besoin. Ou change de machine.
Attention cependant au sujet Github & Microsoft, l’acquisition n’est effective que depuis 4 jours, donc Microsoft n’a rien pu faire encore. Les trolls c’était lors de l’annonce du rachat.
Je suis au courant, je ne vois pas le rapport. Je parlais bien de l'hystérie lors de l'annonce du rachat. Et pourtant quand on regarde dans le détails les critiques émises à ce sujet, la plupart sont sans fondement ou applicables à Github d'avant Microsoft.
En effet s'inquiéter de dépendre d'un hébergeur centralisé sans accès au code source du service, ce n'est pas au moment du rachat de Microsoft qu'il faut y penser mais lors de la création du compte à l'origine !
[^] # Re: Les paroles s'envolent, les écrits restent
Posté par Renault (site web personnel) . En réponse au lien Éric Sadin : l'asservissement par l'Intelligence Artificielle ?. Évalué à 5.
N'oublions pas non plus un des intérêts de la vidéo par rapport au texte : tu peux consulter sans être concentré à 100% dessus, quand tu manges, quand tu fais des tâches ménagères fixes (repasser, faire à manger, etc.). La lecture demande quand même de se focaliser dessus.
[^] # Re: C'est vendredi...
Posté par Renault (site web personnel) . En réponse au journal Libre mais.... moche ?. Évalué à 8.
On peut retourner la chose aussi, si j'utilise une application non GNOME sur GNOME, la cohérence est perdue aussi. Est-ce pour autant que je râle car les applications de KDE (ou VLC, ou Firefox, etc.) ne s'adaptent pas à ce qui se passe sur mon environnement préféré ? Non.
Par définition, tu ne peux pas obtenir une application cohérente avec KDE et GNOME en même temps. Ou alors au prix d'une conception très complexe car tu dois maintenir deux interfaces en même temps. Pas gagnée.
Car une cohérence, ce n'est pas juste un thème ou quelques boutons bien placés. C'est aussi l'intégration avec le système comme le menu global ou centraliser la sauvegarde des données comme les contacts de l'utilisateur. C'est aussi le choix des mots dans la traduction comme l'original qui est cohérent. Quand une application X utilise le mot favoris quand le logiciel Y utilise le mot marques pages, cela a une incidence sur l'expérience utilisateur. Puis tu as des petits détails un peu partout sur ce que doit être le look and feel d'une application selon la plateforme. Par exemple pour les formulaires, Qt dresse une liste des différents points de vue : Windows / macOS et KDE : http://doc.qt.io/qt-5/qformlayout.html#details
Des détails du genre tu en as partout. Si Qt / GTK+ par exemple font des efforts d'abstraction ils ne peuvent tout prendre en charge automatiquement car le développeur doit aussi prendre cela en charge lui même pour de nombreux sujets.
Et tu le vois, Firefox, LibreOffice, Steam ou Avast par exemple ne s'intègrent pas parfaitement dans aucun environnement d'exécution. Car c'est très très difficile à réaliser. Alors que les applications de Microsoft sont globalement cohérentes entre elles (quand elles ont été rafraîchies), de même pour GNOME, de même pour Apple, etc. Alors que sur chacun de ces environnement, utilise une application multiplateforme quelconque et tu es sûr que l'intégration ne sera pas parfaite.
D'autant plus que quand tu es multiplateforme, comme Libreoffice ou Firefox, un dilemme se pose. Vaut-il mieux être intégré dans l'environnement de l'utilisateur, quel qu'il soit ? Ce qui est un travail titanesque. Ou vaut-il mieux que l'apparence de l'application soit identique indépendamment de la plateforme sous-jacente ? Ce qui simplifie la vie de son utilisateur en cas d'utilisation du programme dans différents contextes. Ce n'est pas un choix si évident en fin de compte. Comme toujours il faut trouver le compromis acceptable.
Bref, je ne vois pas de raison de taper sur GNOME là dessus. GNOME a une vision propre de ce que doit être un logiciel GNOME en terme d'apparence et d'intégration. Tout est documenté, il y a des procédures pour établir tout cela et essayer que cela forme un ensemble cohérent. Et tu veux que dans le même temps ils abattent un travail énorme qu'aucun autre logiciel ne fait vraiment. Ni Microsoft, ni Apple, ni Google, ni Mozilla, ni KDE (car oui le logiciel de KDE sous GNOME ne s'adapte pas vraiment à son nouvel environnement non plus) ne font ça par exemple. Cela n'est pas un reproche très cohérent si tu veux mon avis. Ce qui est rigolo étant donné le sujet.
[^] # Re: C'est vendredi...
Posté par Renault (site web personnel) . En réponse au journal Libre mais.... moche ?. Évalué à 10.
Mouais. Je trouve que justement GNOME est l'un des rares environnements libres qui cherche une cohérence de son interface tout en restant efficace et agréable à l’œil. Après cela ne plaît pas à tout le monde, c'est normal, mais cracher sur leurs efforts à ce sujet me paraît osé.
[^] # Re: Inférence de types
Posté par Renault (site web personnel) . En réponse à la dépêche Sortie de JDK 10. Évalué à 10. Dernière modification le 10 novembre 2018 à 01:15.
Non, je veux dire que je peux aussi facilement retrouver l'information qui m'intéresse comme le nom de la variable de l'élément itéré. Cette information n'est pas masquée par le bruit de l'imposant nom du type.
Et pourtant en pratique cela fonctionne très bien. Déjà quand tu évites d'avoir des fonctions de 20 kilomètres de long et que tu as un environnement de travail efficace, ça pose de suite moins de problèmes théoriques. Je rappelle qu'en programmation une bonne pratique est d'avoir des portions de codes réutilisables, réduites (des fonctions donc courtes) au maximum ce qui implique peu de variables dans le même scope. Cela allège grandement ta charge de travail pour ta mémoire
Enfin c'est amusant, moi je m'en suis servi, comme d'autres, dans des projets conséquents sans soucis et toi tu juges apparemment sans t'en être servi dans un langage avec un typage fort. Je te propose de tester en pratique avant d'émettre des de telles positions.
Car bon, inférence de types = JavaScript = merde, on a vu mieux comme argumentation. Je ne suis pas fan du JavaScript, mais ses défauts ne sont pas liés à son inférence de type (ou disons que son inférence de types gêne car il est faiblement typé).
Un bon nommage peut largement induire aussi le type de l'objet. Tu te doutes que "i" dans une boucle est un entier, que "it" dans le même cas est un itérateur, que "name" est une chaîne de caractères. Cela aide à la compréhension et évite de devoir se préoccuper du type exact.
Car bon, même avec le type explicite à la déclaration, si tu es à 40 lignes plus bas et que tu as un doute, tu dois revenir en arrière pour vérifier. Ce n'est pas mieux.
Dixit le gars qui n'a jamais expérimenté tout cela au quotidien. Amusant.
Sinon l'inférence de types est également nécessaire pour exploiter les lambdas anonymes. Mais là encore, je sens que c'est une fonctionnalité sans intérêt pour toi.
Tu comprendras quand que le soucis du JavaScript n'est pas l'inférence de types en lui même ?
Le soucis de JavaScript est d'être faiblement typé, avec inférence de types et une faible rigueur de comportements. C'est ce cocktail qui est explosif. Cela tombe bien, beaucoup de langages modernes ont l'inférence de types pour ses avantages, mais ont un typage fort et un comportement rigoureux pour éviter ses effets de bord. Preuve qu'on peut avoir tout cela en même temps sans soucis.
Car ce cocktail, c'est lui qui fait que ta fonction attend un paramètre d'un certain type, que finalement tu lui envoies une valeur d'un autre type et qu'une conversion implicite absurde est appliquée. Le tout au runtime histoire que cela se détecte qu'en vol. C'est vraiment cette combinaison qui rend la maintenance d'un code JavaScript délicat.
Avec l'inférence de types et un typage fort, cela n'arrive pas. Tu n'as pas le type explicité partout, mais en cas de conflit le compilateur te prévient et tu résous cela en corrigeant le bogue ou en créant une conversion explicite du type A vers B si cela a un sens. Donc en cas de refactorisation tu es gagnant, tu peux changer le type d'une variable (passer de int à long, améliorer le nom de ta classe) sans devoir tout ressaisir (il y aura un peu de travail évidemment mais moins). Et tu allèges considérablement le code d'informations qui sont essentiellement redondantes ce qui rend le code plus aéré et donc lisible.
[^] # Re: Inférence de types
Posté par Renault (site web personnel) . En réponse à la dépêche Sortie de JDK 10. Évalué à 10.
Je ne vois pas le rapport. Le problème de JavaScript ou de Python à ce niveau c'est que tu peux avoir une variable de type entier qui est passé à une fonction où le type attendu est une chaîne de caractères ou inversement.
Là tu parles d'un cas où l'inférence de type a retrouvé le type tout seul et a pu appeler une méthode qui est du bon type. Du coup il n'y a pas de comportement bizarres à prévoir. D'autant plus que le compilateur ne fait pas des divinations très poussées, cela reste souvent assez élémentaire.
Quand tu écris :
Tu crois qu'il va comprendre quoi ? Ce sera évident le type résultant. Et c'est 90% des cas où l'inférence de type sera utilisé. Le compilateur ne va clairement pas se vautrer sur ça. Car quand ce n'est pas assez clair ce qu'il doit faire, il va râler.
Grâce au typage fort et à la simplicité de l'écriture, cela fonctionne mieux que sans. Testé et approuvé.
J'ai dis C++ moderne (donc C++11, 14 ou 17). Le C++ à la C avec des pointeurs nus et des casts implicites et compagnie cela ne se fait plus dans les projets modernes (ou ne devraient pas se faire). Bientôt tu vas me parler de Java 1 aussi ?
Note que Rust et OCaml sont eux irréprochables en terme d'inférence de type et de typage fort. Des langages de conception modernes n'ayant aucun historique à porter là dessus.
L'inférence de type est un outil, si tu trouves qu'à un moment c'est plus lisible d'être explicite, fais-le. Cela ne signifie pas que la fonctionnalité est mauvaise pour autant.
Je ne parle pas de gagner en temps de frappe, quoique. Mais un code peut avoir des types à rallonge. Du coup tu perds en lisibilité car ton code sera dense qui va noyer ce qui est réellement important.
L'exemple le plus connu est sans doute les itérateurs en C++. Je préfère mille fois lire ça :
Ou mieux encore :
Que :
Car oui tu peux rapidement avoir des noms complexes du genre, et je te passe le cas quand c'est un tuple, une map ou autre qui peuvent grossir la taille de la déclaration.
Si tu fais des fonctions courtes, que tes variables et méthodes sont bien nommées (bref, respecter les bonnes pratiques) tu es largement gagnant à utiliser l'inférence de type. C'est comme râler sur les templates, lambda, etc. en pointant sur un cas de mauvaise utilisation. Alors que pourtant ils sont utiles aussi. C'est comme tout, faut pas en abuser mais on n'a aps à s'en priver.
[^] # Re: Inférence de types
Posté par Renault (site web personnel) . En réponse à la dépêche Sortie de JDK 10. Évalué à 10.
L'inférence de type n'a rien à voir avec typage fort ou non.
L'inférence de type est utilisé en C++ moderne, OCaml ou Rust par exemple alors qu'ils sont également fortement typés.
L'inférence de type signifie que le compilateur va déduire à partir du contexte le type de l'objet en question. S'il y arrive bien sûr. Une fois le type assigné à l'objet en interne, il va s'assurer que cela est cohérent avec le reste du programme. S'il y a conflit, une erreur va sauter à la compilation pour prévenir l'utilisateur que justement sa déclaration n'est pas bonne et qu'il doit le résoudre manuellement quelque part.
L'inférence de type permet surtout un code plus lisible et maintenable, en évitant les noms à rallonge de partout, qu'au moindre changement de nom tu aies une cascade de changements connexes à effectuer ou vérifier si ton éditeur t'aide. Et grâce au typage fort justement, tu as la garantie que les données sont correctement manipulées et représentées. Au moindre problème de ce côté, cela ne compilera de toute façon pas. Il n'y a rien de caché au programmeur.
[^] # Re: systemd32.exe
Posté par Renault (site web personnel) . En réponse au journal [HS] Microsoft ♥ Linux - Episode IV L'attaque des clones. Évalué à 5.
En fait comme SysV ne fait pas grand chose en tant que tel et que cela repose sur des scripts qui peuvent faire n'importe quoi, ton système peut être bloqué par un script d'init mal fait.
Donc oui, ce n'est pas init qui bloque, mais le design d'init SysV reposant sur la multitudes de scripts environnants pour faire son job (démarrer ou couper la machine), il faut en tenir compte dans l'évaluation.
Sinon faut être juste et ne pas compter les soucis avec dbus comme des problèmes liés à systemd…
Je n'ai pas dit que tu n'as pas utilisé systemd. Relis bien. J'ai dit que tu avais un avis négatif sur systemd avant même de t'en servir. Comme souvent dans cet état d'esprit, on monte en épingle le premier soucis rencontré sans relativiser son expérience par rapport à son propre passé avec une solution concurrente.
Mais c'est bien d'avoir des couches. Le but de ces couches est de mutualiser le travail, ne pas réinventer la roue, avoir des composants plus solides.
systemd mutualise des tas de comportements. Et c'est très bien. L'init à la SysV c'est historique, c'est initialiser une machine à l'ancienne. C'était bien à l'époque mais le monde a évolué.
Bientôt tu vas rejeter les bibliothèques comme Qt, GTK+, Boost, glibc ou même le noyau car cela mutualise et ajoute des couches ? Réutiliser c'est l'essence même d'une bonne conception.
Oui un système plus complexe peut avoir plus de problèmes. Mais cela apporte plus de choses. cela n'a rien de spécifique à systemd et je ne vois pas en quoi cela est un soucis. Systemd a par design des tas d'avantages. Certes il y a des inconvénient, comme tout logiciel il y a des compromis de conception. C'est dommage mais un choix doit être fait.
Et bizarrement, il n'y a pas grand monde pour se bouger à maintenir les scripts init à l'ancienne, preuve que pas grande monde trouvait SysV si bien que cela à maintenir et à l'usage…
Lol, systemd c'est pareil alors.
Le noyau Linux par sa conception fait beaucoup de choses. Suivant certaines conceptions comme micro-noyau, Linux fait vraiment trop de choses par lui même. Son cœur est trop gros. C'est un choix assumé par conception et l'histoire a montré que ce n'était pas absurde.
systemd, c'est exactement pareil, on peut faire autrement mais l'histoire montre que les choix opérés ont un sens et que le gain l'emporte sur les inconvénients.
[^] # Re: systemd32.exe
Posté par Renault (site web personnel) . En réponse au journal [HS] Microsoft ♥ Linux - Episode IV L'attaque des clones. Évalué à 7.
Ce qui ne veut pas dire que cela n'est jamais arrivé à quiconque. Sous l'ère SysV, plusieurs fois j'ai du achever le redémarrage à la fin moi même.
Bref, tu utilises un cas personnel isolé (à priori ça t'es arrivé une fois, pas régulièrement) pour critiquer un projet que tu n'aimes pas avant même de t'en servir. C'est débile, c'est tout, que ce soit pour critiquer systemd, Firefox, Windows ou iTunes.
D'autant plus que oui, comparer SysV et systemd n'a pas forcément un grand sens sans tenir compte de tous les éléments. systemd est plus gros, peut donc avoir plus de bogues mais il apporte plein de fonctionnalités utiles que SysV ne propose pas et qu'il faut gérer manuellement (donc risque de bogues, peu de mutualisation, maintenance lourde), etc.
C'est comme critiquer Linux qui a plus de bogues que Minix ou GNOME qui consomme plus de mémoire que i3. C'est facile pour un petit projet de gagner dans ce genre de comparaisons, car ils ne font pas la moitié de ce que font les autres projets donc forcément quand tu ne fais pas grand chose, peu de chances de planter directement…
[^] # Re: systemd32.exe
Posté par Renault (site web personnel) . En réponse au journal [HS] Microsoft ♥ Linux - Episode IV L'attaque des clones. Évalué à 7. Dernière modification le 08 novembre 2018 à 23:55.
Car c'est connu que SysV et les autres composants équivalents à systemd n'ont jamais eu de bogues et n'avaient aucun inconvénients.
[^] # Re: Vous l'avez quand même cherché
Posté par Renault (site web personnel) . En réponse au journal Le roi est mort, Vive le roi !. Évalué à 6. Dernière modification le 05 novembre 2018 à 14:01.
Bien sûr, mais bon, c'est toi ici qui vient rapporter le fait que tu as eu un système down quelques temps probablement à cause de la carte SD.
On t'explique juste que la carte SD pour ce type d'usage ce n'est pas top, et pourquoi cela ne l'est pas. Après tu fais ce que tu veux.
Merci mais je travaille dans le secteur quand même, je ne viens pas balancer des idées reçues sorties de nulle part.
Disons que dans le milieu comme je l'ai dit, si ton stockage principal est une carte SD ou eMMC, si tu ne veux pas serrer des fesses à chaque fois que ton appareil s'éteint de manière non propre, tu configures le tout pour minimiser le risque.
C'est tout. Après tu fais ce que tu veux.
[^] # Re: Vous l'avez quand même cherché
Posté par Renault (site web personnel) . En réponse au journal Le roi est mort, Vive le roi !. Évalué à 7.
Tu n'as pas compris nos messages : la moindre coupure de courant dans ton montage actuel peut corrompre le contenu de la carte SD.
Après tu fais ce que tu veux.
Arrête ton char, si les mémoires flash (SSD inclus) ne sont pas d'une fiabilité parfaite (breaking news, aucun système de stockage n'est fiable à 100% en cas de coupure de courant prématurée) on est très loin des problématiques de la carte SD au quotidien.
[^] # Re: Vous l'avez quand même cherché
Posté par Renault (site web personnel) . En réponse au journal Le roi est mort, Vive le roi !. Évalué à 4.
D'autant plus que le bus USB est partagé avec le bus Ethernet. Donc pour un usage serveur cela introduit de la latence et une plus longue durée pour envoyer la réponse. En particulier pour un gros fichier par exemple.
[^] # Re: Eh ben non...
Posté par Renault (site web personnel) . En réponse au journal KDE is dying. Évalué à 7.
Où est-ce qu'ils disent que KDE est obsolète et qu'ils dénigrent le projet ?
Les notes de version à ce sujet sont neutres, ils disent juste que le projet n'est plus pris en charge par le support de Red Hat.
deprecated ne signifie pas obsolète et n'a rien d'insultant.
[^] # Re: Vous l'avez quand même cherché
Posté par Renault (site web personnel) . En réponse au journal Le roi est mort, Vive le roi !. Évalué à 9.
Les cartes SD peuvent être utilisées dans les systèmes embarqués mais pas n'importe comment. Sinon on obtient des pannes comme celle que tu viens d'avoir. Par ailleurs on privilégie les eMMC, assez proches en tant que tel mais plus robuste d'un point de vue électrique et mécanique en général.
Typiquement on limite au maximum les écritures (un maximum de boulot se fait en RAM, les écritures se font de manière régulières mais à des périodes définies). On désactive parfois le wear leveling, on interdit les cellules multi niveaux (enregistrer plusieurs bits dans une seule cellule). Le système d'exploitation est dans une partition en lecture seule, donc séparé des données à sauvegarder.
Bref, oui on trouve des cartes SD dans des systèmes embarqués. Mais cela ne s'improvise pas. Comme tu peux le voir, il y a des techniques à respecter pour que cela soit viable. Faire comme tu le fais serait une catastrophe potentielle à chaque coupure de l'appareil ce qui n'est pas acceptable en production.
[^] # Re: Le plein s'il vous plait
Posté par Renault (site web personnel) . En réponse au journal [Aujourd'hui c'est vendredi] prix du carburant, association d'automobilistes. Évalué à 3. Dernière modification le 02 novembre 2018 à 08:44.
Je cite le début de son article à ce sujet, seul moment de réserve de sa part :
Mouais, je trouve quand même que pour quelqu'un qui veut apporter un nouvel éclairage sur la question, il laisse trop d'éléments dans l'ombre pour que sa thèse soit réellement défendable. Et il prétend par là que son avis provient d'une analyse scientifique. Quand tu affirmes que tu bases ton analyse sur la physique pour donner du crédit à ton propos, tu insinues que ton raisonnement est scientifique. Il a les bases, mais très clairement ça manque de profondeur comme je l'ai souligné.
Oui mais non quand même. L'Italie a ses problèmes mais ce n'est pas non plus un pays incapable de faire du commerce mondial et incapable de payer plus cher des fournisseurs d'hydrocarbure pour alimenter son économie. En tout cas je pense que cette thèse qui est quand même assez fondamentale dans son explication mériterait une analyse complète pour expliquer en quoi c'est le cas. Car cela n'a vraiment rien d'évident.
Je ne dis pas que cela n'arrivera pas dans un futur proche. Je suis convaincu que cela peut être le cas. Mais je ne suis pas convaincu que cela soit arrivé encore. Et encore moins que cela touche la 7-8e économie mondiale et pas un pays comme le Portugal par exemple.
Je trouve qu'en soit il apporte des pistes intéressantes, à creuser. Je ne renie pas cela. Cependant je fais très attention à ne pas prendre pour acquis ce genre de thèses tant que cela manque de rigueur dans l'analyse. Ce que certains font hélas.
La révolution industrielle n'a pas été un mouvement mondial spontané. C'est ce qui explique pourquoi il y a un siècle d'écart dans le document. Globalement on peut séparer en trois groupes :
Tu noteras que globalement les trois démocraties que j'ai cité sont toujours nées avant les débuts de la révolution industrielle localement. Donc je persiste et je signe, la démocratie peut vivre sans une énergie abondante et peu chère. Cela peut aider les choses bien sûr dans ce processus mais il ne semble pas indispensable.
D'autant plus que ces dates approximatives sont le début du processus de la révolution industrielle dans chaque pays ou région, il faut un certain temps avant que cela ait un impact sur la population concret. Ce n'est pas avec une ligne de chemin de fer et une usine que tu changes drastiquement une vie nationale ! Il en faut un peu plus.
[^] # Re: Signification de "Promotion Sociale" pour les non-belges ?
Posté par Renault (site web personnel) . En réponse à la dépêche Se former à Linux en promotion sociale en 2018-2019. Évalué à 7.
Et cela fonctionne aussi pour les étrangers ! ;-)
Typiquement je suis des cours de néerlandais par ce biais depuis peu, 3h / semaine pour l'année scolaire complète revient à 68€ en tout. C'est en effet pas cher pour une formation.
[^] # Re: L'important : les finitions.
Posté par Renault (site web personnel) . En réponse au journal Ubuntu, Fais moi rêver !. Évalué à 6.
Car c'est un exercice plutôt compliqué.
Sous GNOME avec Wayland ça marche.
Fedora fait des tests à ce sujet, c'est pour bientôt. ;)
[^] # Re: Le plein s'il vous plait
Posté par Renault (site web personnel) . En réponse au journal [Aujourd'hui c'est vendredi] prix du carburant, association d'automobilistes. Évalué à 4.
Non, mais une analyse historique mérite plus qu'une phrase balancée comme ça sans preuves.
D'autant plus que dans le cas britannique, américain et français il n'y avait à l'époque pas de machines à vapeur. Ce qui contrarie pour moi la thèse.
La démocratie française a été tumultueuse au début oui. Mais les bases ont été jetées malgré tout. Tu noteras que la démocratie britannique et américaine ont été stables très tôt et bien avant la disponibilité de l'énergie pas chère en abondance.
Je ne dis pas après que ce qu'il dit est totalement absurde et est sans intérêt. Mais cela manque clairement de recul et d'analyse. Je me méfie donc de ses thèses sur le sujet car oui, cela reste douteux en l'état.
Je ne dis pas que les économistes qui passent à la télé font mieux tu noteras.
Mais voilà, Jancovici veut adopter une méthode scientifique pour soutenir son propos. Et globalement il le fait bien. C'est justement ce qu'il me chagrine, c'est que parfois il tient des discours francs alors que la valeur scientifique de son propos est faible.
Je ne dis pas que le lien PIB / énergie n'existe pas. Il est vrai, si demain tu supprimes l'approvisionnement d'énergie d'un pays, son PIB va chuter. En ce sens, je suis d'accord avec lui.
Mais le cas italien comme il l'a analysé a plusieurs soucis de raisonnement, qu'il ignore et n'explique pas. Or pour moi, ces éléments remettent en cause sa conclusion, au moins partiellement.
Je m'explique. L'économie est sans doute l'un des domaines les plus complexes à analyser. Car l'économie est influencée par des tas de facteurs : politique, éducation, sociologie, scientifique, géostratégie, l'histoire, etc. Débarquer en disant que la crise italienne provient d'un manque d'énergie en basant son raisonnement sur l'analyse de données qui concerne uniquement l'objet de sa thèse, ce n'est pas sérieux. Il faut analyser des tas de données, et montrer que seules les données allant dans le sens de sa thèse expliquent la situation avant de conclure. Sinon c'est un travail bâclé voire manipulatoire.
Car dans son article, il a montré une corrélation. Troublante, mais cela reste une corrélation. Une corrélation ne fait pas un lien de cause à effet. C'est pourquoi avant de conclure il doit analyser le reste, pour prouver le lien de cause à effet. Tout en essayant de se prémunir de certains biais comme le paradoxe de Simpson.
Bref, cet article n'est pas un travail de qualité. C'est digne d'un discours manipulatoire basé sur trois graphes pour aller dans le sens qu'il veut. Moi aussi avec deux graphes je te prouve que le réchauffement climatique n'est pas lié à l'Homme. Pourtant bizarrement, si je le fais, on m'en demandera (à raison) un peu plus avant de conclure. Jancovici semble touché par un phénomène répandu chez les experts, dès qu'on sort légèrement du domaine d'expertise (ici l'analyse du climat et le lien avec la consommation d'énergie), il essaye de tout expliquer à partir de son domaine d'expertise. Quitte à juste rassembler les éléments allant dans son sens mais ignorant le reste.
L'autre point gênant et pas des moindre qu'il n'explique pas. Pourquoi l'Italie est le seul pays riche, de l'OCDE tout ce qu'on veut qui manquerait d'énergie ? La 7e économie du monde aurait plus de mal à payer ses fournisseurs étrangers que des pays plus petits et moins riches comme le Portugal ? Cela ne me semble pas cohérent et logique. Du coup le manque d'explication à ce sujet serait même un indice que le problème italien est ailleurs qu'une difficulté d'approvisionnement en énergie. Et que la baisse de l'énergie consommée et du PIB serait due à autre chose.
[^] # Re: Petite précision sur les processeurs sse2
Posté par Renault (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 8.
Ici c'est communiqué dans la dépêche, que veux-tu de plus ?
[^] # Re: Petite précision sur les processeurs sse2
Posté par Renault (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 10.
Chez Fedora pour obtenir cette information tu as deux fichiers à regarder.
La doc des variables globaux utilisés pour générer les RPMs de la distro
Ici la ligne qui définie les options spécifiques pour les paquets i686
[^] # Re: Petite précision sur les processeurs sse2
Posté par Renault (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 10.
Je n'aime pas non plus cette solution mais parfois elle s'impose.
Déjà comme je l'ai dis, avant de recourir à cette solution extrême, regarder du côté de logiciels et de distributions adaptées pour de vieilles configs de ce genre est je pense une bonne idée. Une distribution ne peut pas satisfaire tout le monde à la fois. Vouloir l'extrême nouveauté de chez Fedora tout en étant compatible sur de vieilles machines me semble illusoire.
Sinon, il est normal que de plus en plus de logiciels nécessitent (comme Firefox) d'instructions modernes du processeur. Pour des raisons de maintenances et de tests, c'est plus raisonnable (les ressources ne sont pas infinies côté humain aussi). Mais aussi, renoncer à utiliser du SSE2 alors que globalement quasiment tout le monde a un processeur compatible est un gâchis de ressources aussi. À quoi sert d'avoir du SSE2 dans le processeur si c'est pour ne jamais l'employer ?
D'autant plus que globalement de nombreux logiciels comme Firefox ne sont pas agréables au quotidien sur de vieilles machines. Le Web est devenu trop lourd avec le temps. Et pour naviguer sur des pages légères, il y a des navigateurs plus indiqués que Firefox pour cette tâche par exemple.
De toute façon on le voit que ces configs deviennent rares, rares au point que certains bogues très bloquants ne sont repérés que des mois ou années après l'introduction du problème. Car il n'y a plus assez d'utilisateurs dans la communauté pour tester, utiliser ou maintenir cette compatibilité.
Et comme le Logiciel Libre n'impose rien en tant que tel, si les gens utilisant des processeurs aussi anciens sont motivés, ils peuvent maintenir la compatibilité eux mêmes. Le soucis est que globalement les codeurs restent rarement aussi longtemps avec ce genre de machines. Et on ne peut pas les forcer à le faire.
[^] # Re: Adresse pro
Posté par Renault (site web personnel) . En réponse au message Quelle adresse email utiliser sur un projet Libre dans le cadre du travail ?. Évalué à 7.
Par défaut tu as raison, dans l'absolu non. C'est à l'entreprise de décider quelle politique adopter à ce sujet. Elle peut accepter que cela se fasse avec une adresse courrielle perso mais avec la licence qui désigne l'entreprise.
Tout est possible, il faut en discuter avec l'entreprise ou ses responsables. C'est tout. Mais par défaut oui, l'adresse professionnelle doit être utilisée.
[^] # Re: Petite précision sur les processeurs sse2
Posté par Renault (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 10.
C'est vrai, mais malgré tout cela reste de vieux processeurs. Déjà l'image i686 est régulièrement menacée de disparition car les images x86_64 dominent largement (on est de l'ordre 95% d'accès aux dépôts pour les x86_64 pour 2-3% pour i686). Et encore certains utilisent des images i686 sur des processeurs compatibles x86_64.
Le soucis régulier est que Fedora ne marche pas toujours bien sur cette plateforme. Pendant des mois le noyau Linux n'était pas très opérationnel (mais c'était le cas en amont aussi). De nombreux logiciels abandonnent la maintenance ou les tests sur i686 ce qui n'est pas sans poser problèmes pour la maintenance. Donc même si Fedora faisait un effort, peu à peu le nombre d'applications compatibles baisse. Comme tu l'as mentionné, cela fait un moment que c'est le cas pour Firefox par exemple.
Je te déconseille vivement d'utiliser Fedora sur cette machine (ou alors sans accès à Internet). Fedora 24 est assez ancien et la plupart des composants du système ont donc des failles de sécurité connues et non résolues.
Prends une distribution et des logiciels plus adaptés à ton besoin. Ou change de machine.
[^] # Re: Microsoft en rêvait
Posté par Renault (site web personnel) . En réponse au journal IBM achète Red Hat. Évalué à 4.
Ouais enfin racheter Suse ou Canonical pour Oracle cela ne fait pas forcément sens stratégiquement. Surtout le second qui n'est pas (trop ?) rentable.
Ce n'est pas nouveau que les boîtes à succès se fassent racheter, à moins qu'elles ne deviennent grosses elles même à leur tour.
C'est arrivé, Novell s'est débarrassé de Suse et cela se passe bien apparemment pour eux.
[^] # Re: Microsoft en rêvait
Posté par Renault (site web personnel) . En réponse au journal IBM achète Red Hat. Évalué à 6.
Je suis au courant, je ne vois pas le rapport. Je parlais bien de l'hystérie lors de l'annonce du rachat. Et pourtant quand on regarde dans le détails les critiques émises à ce sujet, la plupart sont sans fondement ou applicables à Github d'avant Microsoft.
En effet s'inquiéter de dépendre d'un hébergeur centralisé sans accès au code source du service, ce n'est pas au moment du rachat de Microsoft qu'il faut y penser mais lors de la création du compte à l'origine !