Le terme "Logiciel Libre" a été inventé par Stallman (et je pense qu'on peut laisser à son créateur la définition d'un terme) pour promouvoir une certaine idée de redonner le pouvoir à l'utilisateur du logiciel (avec donc une philosophie et des valeurs derrière)
À peu près tout le monde est d'accord pour dire que l'OSI a la main sur la définition du terme OpenSource et Stallman / FSF sur le terme Logiciel Libre.
Là n'est donc pas la question. Dans mon argumentaire je conserve ce principe.
Mais la définition d'un Logiciel Libre ou d'un logiciel OpenSource se base uniquement sur les 4 (ou 10) points de leur définition. Rien d'autre. Les à côté de l'esprit du libre ne sont pas explicites, c'est volontairement flou et n'entrent pas en compte dans la définition d'un logiciel libre.
Un logiciel est qualifié de libre ou d'opensource uniquement à partir du choix de licence. Or toute licence libre est opensource et inversement (oui j'ignore volontiers les deux licences quasiment inutilisées en vrai et dont la divergence repose sur des détails et non des divergences fondamentales).
Il est assez clair par exemple que Torvalds défend plutôt le terme et la vision OpenSource. Là où Stallman vise plutôt le côté Libre. Pourtant, Linux comme Emacs sont des logiciels libres et OpenSource malgré des idéaux politiques / économiques / autres différents entre les deux développeurs. Car le Logiciel Libre ne repose que sur sa définition en 4 points. Les à côtés qui sont la source de divergence entre eux n'entrent jamais en compte dans cette qualification.
On notera que ni la FSF, ni l'OSI, n'imposent une quelconque restriction politique ou de valeurs derrière un logiciel libre ou opensource. C'est fait consciemment.
Et c'est très bien, car ce que l'on nomme l'esprit du libre n'est pas défini et je le constate en vrai que beaucoup de gens ont des visions différentes de ce qu'est cet esprit du libre. Comme souvent en politique quand on cherche à défendre des valeurs vagues et floues, il y a différentes interprétations où chacun est pourtant convaincu d'être dans le vrai. Et ce flou pose un problème en communication et en représentativité.
Il suffit de voir en politique pour constater que cela ne fait du bien à personne d'avoir plusieurs partis communistes (chacun étant convaincu d'être le vrai), socialistes ou gaullistes, etc. Cela ne rend pas le discours clair pour ceux qu'on doit convaincre.
Bref, l'avantage ici c'est qu'on a des termes précis, qui sont identiques mais où chaque organisation utilise son terme avec une vision politique différente pour convaincre différents publics. Mais cela revient in fine au même. Que VLC soit qualifié de libre ou d'OpenSource ne change rien pour personne, le code a la même licence et offre la même chose à tout le monde. Et c’est ça qui est important dans le fond. Le reste n'est qu'un aspect marketing.
La question serait plutôt, pourquoi on devrait différencier Logiciel Libre et OpenSource ?
La définition de ces termes est respectivement basé sur les définitions de la FSF et de l'OSI respectivement. Or, quand on lit les critères pour qualifier un logiciel comme libre ou opensource, les critères sont une bijection. Et ce n'est pas un hasard, les fondateurs de l'OSI étaient impliqués dans le LL (Eric Raymond, Ian Murdock) et ils ont voulu maintenir la compatibilité des définitions.
L'OSI est surtout un moyen juridique pour contourner la communication de la FSF. Et on ne peut pas dire que Stallman soit un bon communicant. L'OpenSource cherche donc avant tout de professionnaliser le milieu en évitant que le seul discours du LL soit celui de Stallman.
Le fait que dans la réalité un logiciel libre est toujours opensource et inversement rend en effet ces termes interchangeables.
En réalité, employer un terme ou l'autre ne change rien pour le logiciel en question. Mais cela peut juste traduire la motivation derrière ce choix de licence.
Typiquement on se doute que Stallman et Torvalds n'ont pas choisi la GPL pour les mêmes raisons, l'un privilégie la question politique et éventuellement sociale quand Torvalds souhaitait plutôt obtenir des retours de personnes qualifiées. Mais Linux n'est pas pour autant moins libre que Hurd, ni plus OpenSource que Hurd. Car les définitions d'OpenSource et de Logiciels Libres ne se préoccupent que de 10 ou 4 points techniques dans les licences, ils se moquent éperdument de la motivation de son auteur.
Car s'il a toujours été prouvé qu'elle était constante peut-être ne l'est elle pas tout a fait.
C'est une objection de certains opposants à cette décision. Ça a été évalué.
Est-ce un plus gros problème que de tout reposer sur des objets physiques qui évoluent de manière certaine ? Je ne pense pas, et apparemment c'est l'avis qui a été suivi.
Autre argument, la constante e Planck est connu et défini par la physique Quantique qui c'est révélé incompatible avec la relativité général. Alors même si elle est largement prouvé on sais qu'elle est éronnée à certaines échelles et donc peut-être fausse si on lui demande beaucoup de précision.
Il n'y a pas de relations entre la constante de Plank et l'incompatibilité entre la relativité générale et la mécanique quantique.
C'est comme dire que la constante de la gravitation est fausse alors que les lois de Newton sont insuffisantes. La relativité restreinte et générale n'ont pas remis en cause cette constante pour autant. Elles ont remis en question les formules et l'interprétation physique des phénomènes.
À moins que la constante de Plank évolue avec le temps (thèse assez peu probable tout de même), la nouvelle physique qui unifiera les deux grandes théories physiques ne va pas d'un coup rendre la valeur de cette constante différente.
Parce que l'annonce d'une quatrième navigateur mobile chez Mozilla me semble être le bon endroit pour en parler. Tu ne pense pas ?
Le ton de ton discours n'est pas très bienveillant, c'est ça que je critique.
Tu peux être déçu et désolé de la situation tout en ayant une attitude raisonnable.
C'est une question de volonté. Ils font des choix tout simplement. Le manque de temps c'est juste une priorisation différentes. Il semble qu'il soit plus important pour Mozilla faire de la WebVR que d'améliorer l'existant. C'est un choix et ça peut s'expliquer.
Tout à fait, et ? Tu trouves anormal que la priorité ne va pas dans la direction que tu souhaites ? De plus, je doute que les développeurs de WebVR soient impliqués dans les équipes responsables des fonctionnalités ou des projets que tu cites. Donc bon réaffecter ce genre de personnes là dessus n'a pas un grand intérêt.
Je trouve un peu gros de venir mendier des contributions pour Mozilla, il y a un paquet de projets libres qui sont largement plus dans le besoin qu'eux.
Donc parce qu'il y a pire, Mozilla ne peut pas ou ne doit pas accueillir d'autres contributeurs ?
Mozilla a beaucoup de choses à faire, on peut toujours faire plus et mieux. Donc si pour les réaliser plus vite il faut une aide extérieure, où est le problème ? C'est aussi l'un des intérêt du libre, tu veux une fonctionnalité maintenant, bah tu peux t'en occuper. Cela peut arriver plus vite qu'en attendant que le miracle se produise de lui même.
Pourquoi tu râles ? Simple question. Le code est libre, tu peux ajouter les fonctionnalités que tu veux toi même. Les aider.
Il est loin d'être improbable que Mozilla n'ait pas eu le temps de faire ce genre de finitions proprement et que cela arrivera au gré des mises à jour. C'est dommage mais c'est souvent comme ça dans de gros projets.
Puis le Collège de France ne propose pas de formation diplômante, à cause notamment de l'absence d'inscriptions et de suivi du cours.
Donc ce principe est génial pour la culture générale. Pour ceux qui ont l'opportunité d'y assister. Mais si tu souhaites acquérir du savoir pour te reconvertir, cela peut être difficile à valoriser sur le marché du travail.
Sans porter de jugement de valeur, faire la cuisine en regardant la télé, manger en regardant la télé… Bon, OK, tout le monde l'a probablement déja fait, mais ça n'est quand même pas une bonne idée à généraliser, si?
Ça dépend de chacun, je ne vois pas le problème à le faire. C'est sûr que si tu as une famille ce n'est pas la même chose que si tu es célibataire.
Il y a des domaines où un flux audio est exploitable. En voiture, quand on marche ou qu'on fait du sport, dans les transports en commun… Mais là, on parle de vidéo, pas de flux audio. Du coup, il y a certainement des informations visuelles qui passent, et tu prends le risque de louper des trucs.
Une interview a rarement besoin du signal vidéo. Ou cela devrait être explicitement déclaré en début d'émission. C'est comme la radio qui est filmé (et souvent accessible sur la TV), pourtant tu peux suivre le discours en voiture sans l'image sans soucis. Je ne vois pas de problèmes spécifiques là dessus.
En plus, on parle là de sujets complexes, sur lesquels il faut en permanence faire preuve d'esprit critique, c'est quand même pas facile en faisant du sport ou en coupant des oignons. Bref, pas convaincu…
On dirait que vous jouez votre vie en regardant des vidéos, c'est incroyable. Si tu vois que le sujet est intéressant mais que tu n'arrives pas à suivre, bah tu arrêtes et tu procèdes autrement.
Le débit d'une interview est en général suffisamment faible pour qu'une attention maximale ne soit pas requise pour suivre le truc. D'autant qu'ici vu le gugus et la chaine en question, ton esprit critique doit être activé d'entrée de jeu.
Par ailleurs, il m'arrive de regarder des conférences ou ce genre de vidéos pendant que je fais du vélo d'appartement (donc du sport). C'est impossible de lire un texte convenablement ainsi, alors que la vidéo ça passe très bien.
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.
[^] # Re: Libre ou open source ?
Posté par Renault (site web personnel) . En réponse à la dépêche Revue de presse de l’April pour la semaine 46 de l’année 2018. Évalué à 3.
À peu près tout le monde est d'accord pour dire que l'OSI a la main sur la définition du terme OpenSource et Stallman / FSF sur le terme Logiciel Libre.
Là n'est donc pas la question. Dans mon argumentaire je conserve ce principe.
Mais la définition d'un Logiciel Libre ou d'un logiciel OpenSource se base uniquement sur les 4 (ou 10) points de leur définition. Rien d'autre. Les à côté de l'esprit du libre ne sont pas explicites, c'est volontairement flou et n'entrent pas en compte dans la définition d'un logiciel libre.
Un logiciel est qualifié de libre ou d'opensource uniquement à partir du choix de licence. Or toute licence libre est opensource et inversement (oui j'ignore volontiers les deux licences quasiment inutilisées en vrai et dont la divergence repose sur des détails et non des divergences fondamentales).
Il est assez clair par exemple que Torvalds défend plutôt le terme et la vision OpenSource. Là où Stallman vise plutôt le côté Libre. Pourtant, Linux comme Emacs sont des logiciels libres et OpenSource malgré des idéaux politiques / économiques / autres différents entre les deux développeurs. Car le Logiciel Libre ne repose que sur sa définition en 4 points. Les à côtés qui sont la source de divergence entre eux n'entrent jamais en compte dans cette qualification.
On notera que ni la FSF, ni l'OSI, n'imposent une quelconque restriction politique ou de valeurs derrière un logiciel libre ou opensource. C'est fait consciemment.
Et c'est très bien, car ce que l'on nomme l'esprit du libre n'est pas défini et je le constate en vrai que beaucoup de gens ont des visions différentes de ce qu'est cet esprit du libre. Comme souvent en politique quand on cherche à défendre des valeurs vagues et floues, il y a différentes interprétations où chacun est pourtant convaincu d'être dans le vrai. Et ce flou pose un problème en communication et en représentativité.
Il suffit de voir en politique pour constater que cela ne fait du bien à personne d'avoir plusieurs partis communistes (chacun étant convaincu d'être le vrai), socialistes ou gaullistes, etc. Cela ne rend pas le discours clair pour ceux qu'on doit convaincre.
Bref, l'avantage ici c'est qu'on a des termes précis, qui sont identiques mais où chaque organisation utilise son terme avec une vision politique différente pour convaincre différents publics. Mais cela revient in fine au même. Que VLC soit qualifié de libre ou d'OpenSource ne change rien pour personne, le code a la même licence et offre la même chose à tout le monde. Et c’est ça qui est important dans le fond. Le reste n'est qu'un aspect marketing.
[^] # Re: Libre ou open source ?
Posté par Renault (site web personnel) . En réponse à la dépêche Revue de presse de l’April pour la semaine 46 de l’année 2018. Évalué à 3.
La question serait plutôt, pourquoi on devrait différencier Logiciel Libre et OpenSource ?
La définition de ces termes est respectivement basé sur les définitions de la FSF et de l'OSI respectivement. Or, quand on lit les critères pour qualifier un logiciel comme libre ou opensource, les critères sont une bijection. Et ce n'est pas un hasard, les fondateurs de l'OSI étaient impliqués dans le LL (Eric Raymond, Ian Murdock) et ils ont voulu maintenir la compatibilité des définitions.
L'OSI est surtout un moyen juridique pour contourner la communication de la FSF. Et on ne peut pas dire que Stallman soit un bon communicant. L'OpenSource cherche donc avant tout de professionnaliser le milieu en évitant que le seul discours du LL soit celui de Stallman.
Le fait que dans la réalité un logiciel libre est toujours opensource et inversement rend en effet ces termes interchangeables.
En réalité, employer un terme ou l'autre ne change rien pour le logiciel en question. Mais cela peut juste traduire la motivation derrière ce choix de licence.
Typiquement on se doute que Stallman et Torvalds n'ont pas choisi la GPL pour les mêmes raisons, l'un privilégie la question politique et éventuellement sociale quand Torvalds souhaitait plutôt obtenir des retours de personnes qualifiées. Mais Linux n'est pas pour autant moins libre que Hurd, ni plus OpenSource que Hurd. Car les définitions d'OpenSource et de Logiciels Libres ne se préoccupent que de 10 ou 4 points techniques dans les licences, ils se moquent éperdument de la motivation de son auteur.
[^] # Re: Et si la constante de Planck n'était pas constante...
Posté par Renault (site web personnel) . En réponse au journal Kilo de plume et kilo de plomb. Évalué à 4.
C'est une objection de certains opposants à cette décision. Ça a été évalué.
Est-ce un plus gros problème que de tout reposer sur des objets physiques qui évoluent de manière certaine ? Je ne pense pas, et apparemment c'est l'avis qui a été suivi.
Il n'y a pas de relations entre la constante de Plank et l'incompatibilité entre la relativité générale et la mécanique quantique.
C'est comme dire que la constante de la gravitation est fausse alors que les lois de Newton sont insuffisantes. La relativité restreinte et générale n'ont pas remis en cause cette constante pour autant. Elles ont remis en question les formules et l'interprétation physique des phénomènes.
À moins que la constante de Plank évolue avec le temps (thèse assez peu probable tout de même), la nouvelle physique qui unifiera les deux grandes théories physiques ne va pas d'un coup rendre la valeur de cette constante différente.
[^] # Re: Relou
Posté par Renault (site web personnel) . En réponse à la dépêche Découvrez Firefox Lite pour Android. Évalué à 2.
Le ton de ton discours n'est pas très bienveillant, c'est ça que je critique.
Tu peux être déçu et désolé de la situation tout en ayant une attitude raisonnable.
Tout à fait, et ? Tu trouves anormal que la priorité ne va pas dans la direction que tu souhaites ? De plus, je doute que les développeurs de WebVR soient impliqués dans les équipes responsables des fonctionnalités ou des projets que tu cites. Donc bon réaffecter ce genre de personnes là dessus n'a pas un grand intérêt.
Donc parce qu'il y a pire, Mozilla ne peut pas ou ne doit pas accueillir d'autres contributeurs ?
Mozilla a beaucoup de choses à faire, on peut toujours faire plus et mieux. Donc si pour les réaliser plus vite il faut une aide extérieure, où est le problème ? C'est aussi l'un des intérêt du libre, tu veux une fonctionnalité maintenant, bah tu peux t'en occuper. Cela peut arriver plus vite qu'en attendant que le miracle se produise de lui même.
[^] # Re: Relou
Posté par Renault (site web personnel) . En réponse à la dépêche Découvrez Firefox Lite pour Android. Évalué à 1.
Pourquoi tu râles ? Simple question. Le code est libre, tu peux ajouter les fonctionnalités que tu veux toi même. Les aider.
Il est loin d'être improbable que Mozilla n'ait pas eu le temps de faire ce genre de finitions proprement et que cela arrivera au gré des mises à jour. C'est dommage mais c'est souvent comme ça dans de gros projets.
[^] # Re: Collège de France
Posté par Renault (site web personnel) . En réponse au journal Nouvelle chaire Sciences du logiciel au Collège de France.. Évalué à 7.
Puis le Collège de France ne propose pas de formation diplômante, à cause notamment de l'absence d'inscriptions et de suivi du cours.
Donc ce principe est génial pour la culture générale. Pour ceux qui ont l'opportunité d'y assister. Mais si tu souhaites acquérir du savoir pour te reconvertir, cela peut être difficile à valoriser sur le marché du travail.
[^] # 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é à 4.
Ça dépend de chacun, je ne vois pas le problème à le faire. C'est sûr que si tu as une famille ce n'est pas la même chose que si tu es célibataire.
Une interview a rarement besoin du signal vidéo. Ou cela devrait être explicitement déclaré en début d'émission. C'est comme la radio qui est filmé (et souvent accessible sur la TV), pourtant tu peux suivre le discours en voiture sans l'image sans soucis. Je ne vois pas de problèmes spécifiques là dessus.
On dirait que vous jouez votre vie en regardant des vidéos, c'est incroyable. Si tu vois que le sujet est intéressant mais que tu n'arrives pas à suivre, bah tu arrêtes et tu procèdes autrement.
Le débit d'une interview est en général suffisamment faible pour qu'une attention maximale ne soit pas requise pour suivre le truc. D'autant qu'ici vu le gugus et la chaine en question, ton esprit critique doit être activé d'entrée de jeu.
Par ailleurs, il m'arrive de regarder des conférences ou ce genre de vidéos pendant que je fais du vélo d'appartement (donc du sport). C'est impossible de lire un texte convenablement ainsi, alors que la vidéo ça passe très bien.
[^] # 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.