Renault a écrit 7255 commentaires

Cela fait quelques mois que Fedora propose le paquet firefox-wayland dans les dépôts pour démarrer Firefox avec Wayland. C'est par ailleurs un script qui utilise une variable d'environnement spécifique pour l'activer à chaud sans changer le code de Firefox sous-jacent.

Bref, n'hésitez pas à tester.

En quoi la motivation initiale du développeur compte ? Honnêtement, que Linus Torvalds ait écrit Linux pour le fun, pour répandre la paix dans le monde ou pour obtenir juste le meilleur logiciel possible dans ce domaine importe peu l'utilisateur. Je ne dis pas que c'est inutile comme information, mais cela n'a pas d'impact sur l'utilisateur. L'impact concret est que quelle que soit la motivation initiale, le code source est libre avec les avantages que cela apporte pour l'utilisateur.

Et bizarrement la FSF qui se veut éthique ou avec un certain nombre de valeurs ne rejette nullement le qualificatif de libre pour des logiciels où la motivation ne correspond pas à celle de la FSF. Et de ce fait cette motivation n'est pas requise dans la définition du LL car c'est un sujet à part.

Et dans ce cas, en admettant qu'on tienne compte de la motivation du développeur dans l'équation. Quelles sont les valeurs ou les motivations à respecter ? Qui est juge pour décider ce qui est compatible de ce qui ne l'est pas ? Est-ce que cela est cohérent de refuser d'accorder le qualificatif libre à des logiciels qui respectent les 4 libertés fondamentales dont la 1ère qui précise que l'auteur du logiciel doit autoriser tous les usages de son logiciel ? Même si cela s'avère contre son éthique personnelle.

Bref, OpenSource et Logiciel Libre, c'est juste deux faces d'une même pièce. Cela désigne le même objet, le même concept mais sous un point de vu différent. Mais à la fin on obtient la même chose. Et c'est cela qui est important. La différenciation n'est utile qu'à des fins de communication pour cibler différentes personnes.

J'en ai conscience, mais cela ne semble pas se limiter au cercle des développeurs.

J'ai des amis non développeurs et très fans d'Apple qui sont convaincus de cet état de fait aussi. Il y a j'ai l'impression une grande inconscience collective autour de ce préjugé qui est en réalité assez faux. Ou du moins qui était vrai qu'à l'époque reculée où Adobe a débuté sur Macintosh.

Je trouve cela bien de rappeler que notre OS préféré est utilisé dans le milieu professionnel artistique alors qu'il est souvent décrié comme trop centré sur les développeurs ou pas assez professionnel en dehors d'un usage bureautique très basique ou pour les serveurs.

Ceci dit, c'est une erreur de croire qu'ils cherchent à prendre en charge Wacom uniquement. Le logiciel s'appelle "Wacom Tablet" en effet, mais c'est plus du fait de l'histoire et du monopole. Si tu demandes à son développeur, il te confirmera que c'est censé être un outil générique pour toutes les tablettes graphiques

Je ne dis pas qu'ils ne s'occupent que de Wacom, mais c'est clairement la marque privilégiée pour des raisons de demandes clients.

Typiquement les matériels de tests que certains employés de Red Hat ont sont en effet des Wacom quasi exclusivement car la demande financière est faite pour ces modèles.

Par contre justement le problème du travail que fait RedHat est qu'ils sont tellement à fond sur Wayland que l'amélioration pour X est en gros stoppée depuis plusieurs années. Or le travail graphique sur Wayland est pas prêt du tout encore.

Oui, j'entends bien, après cela vient aussi du fait que de gérer les deux piles en parallèle avec en plus toute l’atrocité de X11 en matière d'entrée rend la chose délicate. Il faut espérer pour toi que cela avance vite. ;)

Tous les 6 mois, à chaque sortie de Fedora, je reteste Wayland pour quelques jours (d'ailleurs faut que je mette à jour et teste Fedora 29 dans les jours à venir). Et à chaque fois, on tombe sur des problèmes bloquants très rapidement donc on est obligé de revenir sur X après avoir créé notre série de rapports de bug

Merci pour ces contributions, je suis certain que c'est utile d'avoir ce genre de retours rapidement.

j'aimerais bien en voir des rapports de bug ou des patchs de Disney ou Pixar, tiens!).

Cela m'étonnerait que cela arrive pour deux raisons. La première est que ces entreprises discutent avec Red Hat et Wacom directement. Pour des raisons de confidentialités, contractuelles et de simplicité de la procédure je doute que toutes ces discussions soient publiques.

De plus, je doute en fait qu'ils soient conscients de ces problèmes. Ces entreprises utilisent RHEL, pas Fedora. Et quand un projet débute, les machines ne sont pas mis à jour avant la sortie du film. Très clairement ils ne passent pas du temps à tester le support dans des distributions plus à jour, et donc ignorent probablement les problèmes les concernant. La question du support est donc délégué à Red Hat, qui fait son développement et ses tests en amont. Les clients font probablement des retours mais pour RHEL uniquement et sans doute pour des problèmes plus mineurs que RH n'a pas identifié.

Bon ensuite ce n'est pas parfait car on est dans une sorte de zone grise: officiellement Wacom ne prend pas en charge Linux (sur n'importe quel site marketing, vous ne verrez jamais une mention de Linux) et en même temps, ils paient des développeurs pour cela. Un peu de schizophrénie d'entreprise, quoi!

Wacom n'est pas la seule entreprise qui bosse dessus, Red Hat fait une grande partie du travail d'intégration noyau - GTK+ - Wayland - GNOME pour les tablettes Wacom. D'où le fait que le travail soit si avancé pour cette marque.

Et cela provient de demandes de certaines entreprises comme Disney / Pixar qui utilisent Linux aussi pour l'animation de leurs films (et non, macOS n'est pas le seul OS du secteur !). Donc ils payent des développeurs de ces deux entreprises pour la gestion des dernières tablettes Wacom.

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 :

auto entier = 0;
auto booleen = false;
auto chaine = "chaîne de caractère";
auto classe_complexe = copie_de_cette_classe;
auto autre_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 :

for (auto it = conteneur.cbegin(); it != conteneur.cend(); it++)
     // Utiliser l'itérateur

Ou mieux encore :

for (auto element : conteneur)
     // Utiliser l'élément

Que :

for (std::vector<UneClassePerso>::const_iterator it = conteneur.cbegin(); it != conteneur.cend(); it++)
     // Utiliser l'itérateur

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…

C'est exactement le genre de truc débile que je prévoyais de rencontrer avant même d'utiliser ce machin.

Car c'est connu que SysV et les autres composants équivalents à systemd n'ont jamais eu de bogues et n'avaient aucun inconvénients.

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.

C'est tout. Après tu fais ce que tu veux.

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.