Sommaire
De l'utilité des mainteneurs
Contrairement au monde Windowsien, il est très peu commun pour un utilisateur de Linux ou BSD (voire même MacOS, avec HomeBrew) d'installer directement un logiciel depuis le site web de son développeur. Le plus clair du temps, on passe plutôt par un dépôt (de binaires ou de sources) : cela permet aux utilisateurs de ne pas avoir à se soucier de la configuration particulière de leur distribution préférée et de centraliser les installations et mises à jour.
Cela met toutefois en exergue le rôle crucial mais trop souvent méconnu de mainteneur. C'est grâce à eux que vous pouvez trouver facilement vos logiciels et que les patchs nécessaires à leur fonctionnement sont appliqués. C'est aussi parfois eux qui maintiennent le logiciel alors que les développeurs originaux (upstream) sont passés à une version plus récente. C'est finalement souvent eux qui remontent les bogues et s'assurent de rapatrier leur correction dans leur distribution. Bref, en tant que développeur, les mainteneurs vous permettent de diffuser gratuitement votre logiciel à des millions de personnes. D'où l'idée de ne pas se les mettre à dos.
La situation
Observons donc ce qu'il ne faut pas faire. Pour résumer l'histoire :
Un bénévole travaillant sur les ports d'OpenBSD décide d'intégrer Pale Moon. C'est un fork de Firefox, et donc un logiciel libre. Il poste un premier message sur les forums de Pale Moon indiquant 1) qu'il faudrait qu'il applique certains patchs pour contourner certains problèmes spécifiques et 2) qu'ayant lu le contrat de licence et ayant constaté que la redistribution sous le même nom ne pouvait se faire qu'avec l'accord des développeurs, il voudrait savoir si un tel arrangement pourrait être fait.
Moins de 2 heures plus tard, une issue est soulevée sur le dépôt GitHub des mainteneurs :
You will revise your mozconfig […] You must comply with the directive or you must disable official branding […] Additionally, you will please explain and justify the patches you are applying
Le ton est toujours difficile à traduire d'une langue à l'autre, mais l'utilisation de will et must est l'équivalent de l'impératif en français.
Le mainteneur (le même qui avait originellement posté sur les forums de Pale Moon) rétorque qu'il souhaite discuter avec le détenteur des droits et non se faire poser des ultimatums ainsi.
Le dit détenteur intervient alors :
Your insistence to only speak to me in person about such matters is ridiculous, considering the license is up on the website, worded clearly for everyone to see, and you're clearly not adhering to it. But, here I am, as requested. Now, follow the license terms, please. I will not be as educational next time.
La dernière phrase étant pour le moins indicatrice de l'état général de la conversation.
- La discussion s'enflamme (des 2 côtés) et, quelques heures plus tard, le mainteneur publie sa décision :
This issue is now officially resolved. There will be no Pale Moon browser, official or not. The port has been removed. Farewell, petulant children.
- Toute cette agitation a amené d'autres BSD à se demander s'ils n'étaient pas aussi en violation de la dite licence et, dans le cas de FreeBSD au moins, il s'avère que oui.
Que retenir
Il y a plusieurs choses à considérer dans cette histoire. Premièrement, le point de vue technique : ce n'est pas par hasard que les distributions veulent compiler les logiciels libres en utilisant leurs propres librairies et directives de compilation. Le tout est très bien résumé dans ce message, mais, pour faire simple, cela permet à la fois de mieux assurer la sécurité de l'utilisateur, de retirer une charge de maintenance des développeurs upstream et de faciliter la mise à jour (contrairement à, par exemple, Windows, où chaque logiciel embarque justement ses propres versions de chaque librairie). Ce genre de restriction est tout simplement impossible à appliquer dans le cas général et dénote une certaine incompréhension de la manière dont les distributions (Linux ou BSD) fonctionnent.
Deuxièmement, le point de vue légal/philosophique : ce genre de restrictions commence sérieusement à s'éloigner des objectifs du logiciel libre. Protéger une marque est une chose, utiliser ce copyright pour mettre en place des mesures restreignant la liberté des utilisateurs en est une autre. Certes, on pourra me rétorquer que Mozilla a fait la même chose avec Firefox (d'où le fork IceWeasel), mais voilà : Mozilla n'est jamais allé aussi loin. Si la diffusion sous le nom de Firefox d'un binaire recompilé à partir de sources modifiées était effectivement prohibée, les mainteneurs ont toujours eu toute la latitude pour modifier les paramètres de compilation.
Troisièmement, le point de vue humain : lorsqu'il y a des gens qui travaillent bénévolement pour diffuser votre travail et font des efforts honnêtes pour vous contacter et prendre votre avis en compte, la moindre des choses est de ne pas leur cracher au visage moins de 3 heures après les présentations. Ce n'est pas de dire que tout développeur dans une situation similaire devrait se garder de toute critique, mais qu'il y a une façon de la formuler. Si vous arrivez sur vos grands chevaux, ne vous étonnez pas d'être reçus avec mépris par quelqu'un qui, au final, ne vous doit rien.
Tout bien réfléchi, la perte de réputation pour Pale Moon (qui est un navigateur de niche) est probablement plus préjudiciable que tout problème ayant pu survenir à cause d'une librairie mal configurée par un mainteneur…
# Lincence MPL et build.
Posté par Sylvain Colinet (site web personnel) . Évalué à 6.
Je dois être idiot. Mais je comprends même pas leur redist point sur le Licencing. La MPL protège tout ce qui est logo et nom, mais couvre pas le système de build. Je vois même pas comment ils peuvent imposer de build avec les libs intégrées patchés (et pas remonter les patchs surement?)
[^] # Re: Lincence MPL et build.
Posté par Kalenx . Évalué à 10.
En fait ce n'est pas une question de licence, mais de copyright. Puisqu'ils possèdent les droits sur le nom Pale Moon (et encore, ce n'est pas très clair), ils peuvent restreindre ou interdire son utilisation. Autrement dit, ils ne peuvent pas empêcher de redistribuer leur code sous un autre nom (par exemple New Moon, comme suggéré par FreeBSD), car ce n'est pas le code qui coince, mais le nom lui-même.
Ceci étant, la plupart du temps, les gens préfèrent avoir le même nom dans les dépôts de leur distribution que sur le net, si bien que même cette restriction "minime" rend le tout bancal.
[^] # Re: Lincence MPL et build.
Posté par jtremesay (site web personnel) . Évalué à 4.
Pour information, New Moon est le nom par défaut des builds non officiels, cf https://github.com/MoonchildProductions/Pale-Moon/blob/master/browser/branding/unofficial/configure.sh#L5.
# Mainteneur
Posté par Gof (site web personnel) . Évalué à 10.
Merci pour le journal intéressant.
Je me pose une question quand à la terminologie du mot « Mainteneur ». Pour moi (développeur), un mainteneur est celui qui développe et maintiens le logiciel upstream. Et le mainteneur du paquet dans la distrib, je l'appellerais plutôt un « packageur ».
Différence de point de vue, sans doute.
[^] # Re: Mainteneur
Posté par gasche . Évalué à 10.
Je suis d'accord avec le nom "packager" (empaqueteur ?) plutôt que "maintainer" ici (être mainteneur c'est un rôle upstream), même si les distributions au niveau local parlent de mainteneur pour "mainteneur du paquet".
Je suis encore plus d'accord avec le fait que c'est un bon journal : une tranche de vie bien racontée.
L'auteur aurait peut-être pu mieux montrer que la situation est toujours un peu plus nuancée que ça. Les développeurs de Pale Moon sont peut-être des désagréables de naissance, mais il est raisonnable de supposer qu'ils ou elles n'ont pas commencé comme ça, et qu'il y a des explications à leur indélicatesse. Comme c'est une version de Firefox concentrée sur les performances, il y a sans doute des choix particuliers qui ont été fait sur les versions des bibliothèques externes ou sur les options de build, et une peur que quelqu'un empaquette incorrectement et que des utilisateurs trouvent ensuite le logiciel plus lent ou plus buggué qu'il ne l'est réellement—c'est peut-être déjà arrivé dans ces conditions-là. Ça n'excuse rien, mais ça permet peut-être de comprendre ce qui a mis les gens dans une situation aussi désagréable.
(Je pense que derrière on pourrait réfléchir plus globalement à cette manie de sortir des versions "remasterisées" de logiciels, pour "optimiser" tel ou tel aspect. Mon expérience est que souvent ces projets sont des pertes de temps, qui ne peuvent structurellement rien changer qui n'aurait été possible par un peu de contribution upstream (changer les options par défaut etc.), et qui manquent de la maîtrise technique pour offrir quelque chose de pérenne. Pas mal de temps perdu au final. Bien entendu, c'est souvent plus nuancé que ça, en particulier dans les domaines où la Q/A (Analyse de Qualité) est importante, parce que le comportement global du système est très sensible au fait d'avoir été bien intégré, bien configuré, etc. Ces spin-off "optimisées" jouent alors surtout le rôle d'une distribution clé-en-main, bien testée, pour un certain profil d'utilisateur sur lequel l'upstream ne se concentre pas. Ça a pas mal de sens pour les distributions multimédia par exemple (audio/vidéo, sensibilité aux latences, configuration de Jack, etc.), je suis un peu moins convaincu pour un navigateur web. Mais ce rôle (qui est en réalité un rôle de packaging, configuration et Q/A) permet aussi de comprendre l'état d'esprit des développeurs de Pale Moon et leur résistance à avoir de nouveau paquets downstream. Peut-être se voient-ils plutôt comme des fournisseurs d'un binaire Firefox bien testé pour les systèmes/distributions qu'ils utilisent eux-mêmes.)
[^] # Re: Mainteneur
Posté par pizaninja . Évalué à 3.
Je croyais qu'on utilisait plus Q/À pour parler d'"assurance qualité" plutôt que d'"Analyse Qualité"…
[^] # Re: Mainteneur
Posté par reynum (site web personnel) . Évalué à 5.
En fait dans le cas présent "mainteneur" est une abréviation de "mainteneur du paquet/package" c'est plus ou moins expliqué dans la première section via les phrases :
Le "mainteneur du logiciel" est plutôt appelé programmeur ou développeur.
kentoc'h mervel eget bezan saotred
# Impolitesse ?
Posté par Olivier . Évalué à 10.
La réponse du développeur, lue dans son intégralité, est très ferme, pleine de lassitude contenue, mais polie. En tout cas, pas plus impolie qu’exiger que l’auteur vienne soutenir ce que le site dit. Ce n’est pas agréable de se prendre un refus, mais qu’est-ce que le demandeur espérait ?
Car, oui, il est un peu ridicule d’avoir à expliquer qu’une licence est censée être respectée. Les dévs n’ont pas fait ce choix par hasard, quoi qu’on en pense. Avoir à le justifier est pénible.
Maintenant, sur le fond de l’affaire (faut-il protéger sa marque ? qui a raison entre les dévs et les packageurs ?), je comprends le choix des dévs. Ce n’est pas pour vous empêcher de faire des changements, c’est pour ne pas avoir à se farcir les problèmes engendrés par les modifications dont ils ne sont pas les auteurs, problèmes qui font venir des utilisateurs qui se plaignent parce que ça ne fonctionne pas (ou pas comme prévu) sur la distrib XYZ qui a cru bon de faire une modification malvenue. Personne n’aime avoir à répondre des erreurs ou des choix d’autrui.
Chez LibreOffice/OpenOffice, on a longtemps déconseillé les versions packagées par les distributions. Et c’est encore souvent le cas. Je ne compte plus le nombre de fois où ce qui fonctionne parfaitement sur la version vanilla bugue ou ne fonctionne pas du tout sur une version packagée. Les packageurs qui ont cru bon de remplacer la dépendance à Python 3.3 par une dépendance à Python 2.7 ou 2.6 m’ont fait perdre un temps considérable. Je conseille toujours d’installer une version “vanilla”. Parce que ce n’est pas nécessairement le seul problème. Qui sait qui fait quoi parmi ces centaines de distribs ?
À mes yeux, l’exigence d’abandonner le nom et le logo d’un produit si l’on en modifie quelque chose signifie : Si vous faites des changements, assumez-en les conséquences, ne nous mettez pas ça sur le dos.
[^] # Re: Impolitesse ?
Posté par totof2000 . Évalué à 4.
Y a-t-il une version vanilia disponible pour free/net/openbsd ?
[^] # Re: Impolitesse ?
Posté par Olivier . Évalué à 4.
Je n’en sais rien. Apparemment non.
Mais tous les packageurs ne font pas des modifications qui suscitent des problèmes.
Le souci, c’est qu’on n’en sait rien. Quand on utilise un paquet proposé par une distrib, comment savoir quelles modifications ont été faites ? Comment sait-on si c’est proche du vanilla ou très éloigné, si les problèmes rencontrés viennent de la distrib ou pas ?
[^] # Re: Impolitesse ?
Posté par Sébastien Le Ray . Évalué à 4.
Ailleurs je sais pas, sous Debian on peut regarder dans le répertoire debian/patches du paquet concerné
[^] # Re: Impolitesse ?
Posté par Michaël (site web personnel) . Évalué à 2.
Sous FreeBSD c'est pareil. Sauf qu'en plus on peut les regarder sans savoir grand chose ;) https://svnweb.freebsd.org/ports/head/www/firefox/files/
[^] # Re: Impolitesse ?
Posté par barmic . Évalué à 9.
C'est pour ça que tu dois remonter les problèmes que tu rencontre a ta distribution qui va ensuite qualifier et remonter un problème mieux qualifié upstream si nécessaire. Mais c'est une généralité en fait, tu va poser la question à celui qui te fourni ton logiciel.
[^] # Re: Impolitesse ?
Posté par Renault (site web personnel) . Évalué à 9.
Exactement, c'est l'un des buts de l'empaqueteur que de faire le lien entre les utilisateurs de sa distribution et le projet officiel. L'utilisateur ne doit pas rapporter un bogue upstream directement (sauf s'il sait ce qu'il fait bien entendu).
C'est le mainteneur du paquet qui doit évaluer si le bogue vient de ses changements ou de la distribution elle même (utilisation d'une bibliothèque différente par exemple) ou si c'est bien le projet upstream.
C'est pour cela que maintenir un paquet dans une distribution sérieuse c'est du boulot, la génération du paquet n'est qu'une partie du travail à effectuer.
[^] # Re: Impolitesse ?
Posté par Jean-Baptiste Faure . Évalué à 5.
C'est un point de vue qui me paraît complètement irréaliste pour un logiciel comme LibreOffice dont les utilisateurs sont vraiment nombreux. L'empaqueteur ne ferait que ça de la journée et passerait son temps à remonter des doublons upstream. Quand on suit les rapports de bug upstream, les bugs spécifiques à une distribution ne me semblent pas si nombreux que ça en fait.
Le meilleur moyen de savoir si un bug vient du packaging de la distribution, c'est justement d'en avoir connaissance upstream et d'essayer de le reproduire sur d'autres distributions et d'autres OS.
[^] # Re: Impolitesse ?
Posté par barmic . Évalué à 3.
Rien oblige à ce qu'il soit seul, mais surtout, c'est une bonne répartition de charge ! Flooder l'upstream n'est pas plus efficace. C'est le contraire ça pas très bien quand il y a peu d'utilisateurs.
Si tu veux plus t'investir et aller plus loin dans la qualification tu trouvera presque souvent des gens bienveillants.
[^] # Re: Impolitesse ?
Posté par Guillaume Smet (site web personnel) . Évalué à 10.
Alors, j'eus eu un paquet Debian pour un de mes logiciels : plein de modifs faites dedans sans même essayer d'en parler upstream (alors que j'étais plutôt super dispo pour parler de ça) dont certaines introduisaient des bugs majeurs (genre le logiciel qui ne fonctionnait plus du tout en activant une option très commune).
Et bien les gens viennent régulièrement remonter le souci upstream. Ce qui est d'autant plus frustrant quand tu ne peux rien y faire et que le mainteneur du paquet ne répond pas du tout à tes mails.
De mon expérience, c'est assez typique de Debian de se permettre des patches en pagaille sur les logiciels sans en parler upstream. C'est beaucoup moins le cas dans les distributions à base de RPM qui ont tendance à fournir des logiciels plus "vanilla".
Même expérience chez Mageia où ils avaient fait une erreur dans les dépendances (c'aurait été trop simple de s'inspirer des RPM existants…), où je me suis retrouvé avec la remontée de bug et où personne n'a répondu à mon mail non plus.
A l'inverse, j'avais un super bon contact avec le packager Fedora/RHEL/CentOS et tout se passait très bien.
Le fait est que ce que l'utilisateur retient, c'est que ton logiciel ne fonctionne pas, pas qu'il a été mal packagé.
Bref, le monde merveilleux des distributions, je dois avouer que ça m'a un peu refroidi. Pour un petit logiciel avec un auteur réactif, ce n'est quand même pas bien dur d'être un peu plus proactif et respectueux, d'autant plus quand ça permet d'arriver à un meilleur résultat.
[^] # Re: Impolitesse ?
Posté par totof2000 . Évalué à 3.
Ca me fait un peu penser à un truc que j'ai lu sur cdrtools : l'autaur du projet vanilia semble-t-il, n'a pas voulu intégrer certains patch du mainteneur de paquet Debian, et ça a fini par un gros fork sous prétexte d'incompatibilité de licence.
[^] # Re: Impolitesse ?
Posté par barmic . Évalué à 5.
Tu es loin d'être le seul à avoir rencontré ce genre de problème. La communauté Debian essaie d'arrêter d'avoir un mainteneur pour un paquet donné, mais de faire ça en équipe. Ça n'apporte que des bonnes choses :
Les remontés de bug directement à l'upstream, Debian tente de les éviter en proposant des outils dans Debian pour simplifier la remonté de bug au sein de Debian. C'est encore loin d'être parfait.
Beaucoup de logiciels ne respectent pas très bien les standards du genre HFS ou tout ce qui vient de freedesktop.
[^] # Re: Impolitesse ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8.
On va parler de comment ça se passe chez Haiku, tiens.
Nos paquets sont construits automatiquement à partir de recettes qui sont sur un dépôt github. On a un certain nombre de contributeurs actifs sur ce dépôt, mais surtout un tas de gens qui font des pull requests: soit des utilisateurs qui avaient besoin d'utiliser un logiciel et qui ont écrit une recette eux-même, soit de plus en plus, des développeurs upstream qui viennent eux-même mettre à jour nos recettes ou au moins nous ouvrir un ticket quand ils publient une nouvelle version (surtout si elle corrige une faille de sécurité).
En échange, on essaie de penser à faire des patchs propres et à les envoyer à l'upstream, même si on est pas toujours très efficaces ou réactifs (c'est qu'on gère beaucoup de paquets à la fois, quand même).
Pour l'instant ça se passe plutôt bien dans l'ensemble.
[^] # Re: Impolitesse ?
Posté par Raphaël G. (site web personnel) . Évalué à 1.
Sur mageia, de quel paquet s'agissait-il ?
Si tu as un peu de temps, je t'invite à créer un compte et demander à être mainteneur de ton paquet, tu seras le bienvenu :)
Je suis contributeur depuis un bon moment, le principal problème, c'est de trouver le temps de s'occuper de ses paquets favoris, les journées n'ont que 24h :p
[^] # Re: Impolitesse ?
Posté par gouttegd . Évalué à 8.
Il s’agit là d’une vision de ce que doit être le rôle d’une distribution et de ses empaqueteurs. Une vision dans laquelle la distribution, entre autres rôles, sert d’intermédiaire absolu entre l’upstream et les utilisateurs.
Dans cette vision, les empaqueteurs se permettent des modifications par rapport à l’upstream parfois conséquentes (et parfois lourdes de conséquences). En contrepartie, ils recueillent toutes les plaintes des utilisateurs (en théorie) et peuvent présenter aux développeurs upstream des rapports de bugs synthétiques, bien construits et probablement plus utiles que ceux provenant directement des utilisateurs.
C’est notamment et notoirement la vision de Debian, mais je veux souligner que ce n’est pas la seule possible. Slackware par exemple, correspond à une idée selon laquelle la distribution est une couche à peine visible. Pour ce qui nous intéresse ici, cela veut dire d’une part que les logiciels ne sont qu’exceptionnellement patchés par rapport aux sources upstream, et d’autre part que les utilisateurs doivent contacter directement l’upstream en cas de bug. Il ne sert strictement à rien de contacter Patrick Volkdering, sauf si on est absolument sûr que le bug vient de la façon dont le logiciel a été empaqueté (j’ai rapporté un bug de ce genre en quinze ans d’utilisation de Slackware).
(Je ne veux pas sous-entendre qu’une vision est meilleure qu’une autre, même si vous aurez sans doute deviné qu’il y en a une que je préfère. :-° )
[^] # Re: Impolitesse ?
Posté par eingousef . Évalué à 8.
Et ce serait bien que les mainteneurs debian renomment les paquets dans ces cas là, même lorsque ce n'est pas une obligation légale, parce que ça peut être perturbant quand tu parles du logiciel en-dehors de la communauté debian.
Par exemple debian retire les firmwares non-libres du kernel, du coup le "linux" de debian gère beaucoup moins de matériel que le "linux" officiel.
Le "abuse" de debian n'a pas de sons, le "freegish" de debian n'a pas de musiques, le "warzone2100" de debian n'a pas de scénario.
On se retrouve avec des logiciels qui sont différent, mais qui ont le même nom. C'est problématique, surtout dans des cas où il est illusoire de penser que tu ne vas jamais parler du logiciel et de ses limites en-dehors de la communauté debian.
*splash!*
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Impolitesse ?
Posté par barmic . Évalué à 6.
Dans la version, ce qui n'est pas forcément très visible.
[^] # Re: Impolitesse ?
Posté par Yth (Mastodon) . Évalué à 6.
J'en rajouterai un peu sur la communauté Slackbuilds pour slackware, qui fournit des scripts permettant de créer soi-même un paquet.
Les patchs sont très rares, et dans les cas complexes comme LibreOffice, Palemoon (en l'occurrence), ou Blender, il y a deux slackbuilds, l'un qui repackage un binaire officiel, et l'autre qui permet de tout recompiler soi-même.
Par exemple : "palemoon" repackage le binaire officiel pour slackware tandis que "PaleMoon" permet de le recompiler.
Et c'est directement indiqué dans la doc des slackbuilds.
Ça rend d'ailleurs bien plus simple de savoir si un bug vient de palemoon ou de la compilation : si on a un bug avec la version compilée qu'on n'a pas avec la version repackagée, on sait qu'on a un soucis à la compilation. Si le bug est présent avec les deux paquets, ça vient probablement du projet lui-même.
Mais je te rejoins largement pour dire qu'il n'y a pas une vision meilleure qu'une autre.
Je te rejoins aussi pour exprimer laquelle je préfère ^
Yth.
[^] # Re: Impolitesse ?
Posté par barmic . Évalué à 4.
Pour le coup les sources des paquets debian sont dispo et tu y trouve le dossier des sources upstream sans le moindre changement. Les patchs appliqués sont dans un dossier spécifiques).
De tête reconstruire un paquet sans les patch ça doit être à peu près :
[^] # Re: Impolitesse ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 14 février 2018 à 10:38.
Je confirme : le paquet Ubuntu de LibreOffice est un cauchemar. Chez moi, ça plante régulièrement, en particulier lors de la sauvegarde, ce qui rend le logiciel inutilisable. Et pourtant ça fait des années que c'est comme ça, parce que bien sûr, à chaque réinstall de mon système, je m'obstine à utiliser les paquets de la distrib. Du coup je me rabat toujours sur les paquets vanilla, et ça fonctionne correctement :)
D'ailleurs je fais de même pour Firefox (et Thunderbird). C'est peut-être la raison pour laquelle je n'ai jamais ces problèmes de lenteur ou de mémoire qu'observent les autres utilisateurs de Firefox.
Bref, je comprend moi aussi que les développeurs de certains logiciels ne veulent pas qu'on build un soft avec des modifications tout en gardant le nom protégé. Pour des logiciels complexes, changer de version de lib peut rendre le logiciel instable.
Maintenant il faut aussi que les développeurs upstream mettent un peu d'eau dans leur vin, en acceptant des patchs qui permettent de corriger des problèmes avec tel ou tel lib ou système. Ça ne peut qu'être bénéfique pour tout le monde.
[^] # Re: Impolitesse ?
Posté par arnaudus . Évalué à 10.
Ils peuvent aussi concevoir leur logiciel pour qu'il soit facilement empaquetable et robuste vis-à-vis des demandes courantes des distributions. Je ne pense pas que l'écriture de gros patches intrusifs soit le but des «empaqueteurs», ils se sentent obligés de le faire pour intégrer le logiciel dans leur distribution, pour tout un tas de raisons (performance, sécurité, interaction avec d'autres composants du système, dépendance à des versions anciennes/récentes de bibliothèques externes, etc).
[^] # Re: Impolitesse ?
Posté par Jean-Baptiste Faure . Évalué à 2.
Ce paquet Ubuntu, tu le fais tourner sur Ubuntu / Unity ou bien sur une dérivée d'Ubuntu ?
Parce qu'il y a les mêmes problèmes avec les distributions et leurs dérivées qu'avec les logiciels upstream vs. packaging des distributions.
[^] # Re: Impolitesse ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Il est vrai que je suis sous Kubuntu.
[^] # Re: Impolitesse ?
Posté par ZeroHeure . Évalué à 3.
C'est rigolo parce que les paquets Debian n'ont pas ces problèmes (à ma connaisance)! Je crois que René Engelhard (empaqueteur Debian) est assez impliqué dans libreoffice, il doit faire plus gaffe — et en effet, le changelog d'Ubuntu indiqaue des changements sur les dépendances.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Impolitesse ?
Posté par Jean-Baptiste Faure . Évalué à 3.
Les paquets Ubuntu non plus à ma connaissance à moi, c'est pour cela que j'aimerais savoir sur quelle distribution ces paquets sont utilisés.
René Engelhard est effectivement un développeur LibreOffice, tout comme Bjoern Michaelsen (Canonical) qui est mainteneur des paquets pour Ubuntu.
[^] # Re: Impolitesse ?
Posté par Kalenx . Évalué à 6. Dernière modification le 14 février 2018 à 13:47.
Oh, je ne prétends pas que les mainteneurs (oui, je maintiens l'utilisation de ce nom ;-) ) sont nets de tout reproche. Certains ont fait remarqué (avec raison) qu'ils ont eux-mêmes eu une attitude quelque peu enfantine et qu'ils auraient pu agir de manière plus mature (be the bigger man, qu'ils disent en anglais). Je ne conteste pas ce fait.
Je ne pense cependant pas que le mainteneur principal ait voulu simplement écarter le premier intervenant pour changer la décision, mais pour changer de ton. Si vous faites une fête chez vous, il peut, dans certaines occasions, être légitime pour le voisin de se pointer pour demander à ce que l'on réduise le bruit. Mais si ce dit voisin débarque avec une mise en demeure et une lettre d'avocat alors que vous êtes spécifiquement allé le voir juste avant la fête pour lui dire de ne pas hésiter à venir vous voir si vous pouviez faire quelque chose pour lui, alors oui, vous allez probablement réagir différement, même si ça ne change pas que sur le fond il ait raison.
Cette licence est extrêmement particulière dans le monde du LL et, pour être franc, il n'est même pas clair qu'elle soit valide. Restreindre la distribution du code source pour des raisons de copyright, alors que le logiciel est sous licence libre, ce n'est pas tout de suite la chose à plus logique à mes yeux. Si on parlait de considérations évidentes telles que l'attribution, alors oui il serait légitime de supposer que le mainteneur en soit conscient (c'est son travail après tout). Mais ici on parle d'un détail extrêmement convolué et extraordinaire (au sens de hors de l'ordinaire) et le développeur ne peut pas s'attendre à ce que ce soit évident pour tout le monde.
Moi aussi, je les comprends. Ce dont je suis convaincu, cependant, c'est que les choses auraient été bien différentes si l'intervenant original avait accepté d'admettre que l'erreur des mainteneurs (on parle d'un dépôt WIP et extrêmement récent) était de bonne foi et aurait en conséquent pu être corrigée sans aucun problème en présentant également le problème de bonne foi, et non en menaçant de "ne pas être aussi gentil et pédagogique la prochaine fois".
[^] # Re: Impolitesse ?
Posté par Olivier . Évalué à -2.
C’est le ton de quelqu’un qui exige que la licence soit respectée. C’est froid et sans aménité, c’est clair. Mais on a vu pire (Linus Torvalds, par exemple, ou sur ce site).
Le problème concerne la distribution des binaires. Et la MPL est claire sur les marques : « This License does not grant any rights in the trademarks, service marks, or logos of any Contributor »
Je ne sais pas. Mais ce n’est pas mon sentiment.
Je cite les auteurs de Palemoon :
Ce que je comprends de tout ça, c’est que les auteurs de Palemoon sont très fermes sur l’utilisation de leur marque, précisément parce qu’on peut facilement s’en passer et faire autrement. Il n’y a aucune limitation si on n’utilise pas l’option --enable-official-branding…
Tout ça n’est qu’une tempête dans verre d’eau.
Ça n’a guère d’importance. Juste une affaire de susceptibilité froissée. Ça arrive.
[^] # Re: Impolitesse ?
Posté par gouttegd . Évalué à 10.
Non, les conditions s’appliquent aussi à la redistribution sous forme de sources (articles 8b et 10).
L’auteur du port a contacté les développeurs de PaleMoon précisément parce que c’est ce qui est demandé dans leurs conditions de redistribution :
Donc, l’auteur du port, désireux de respecter les termes de la license et sachant qu’il a effectivement procédé à des « changements significatifs dans la configuration » (notamment en optant pour l’utilisation des bibliothèques du système), contacte les développeurs upstream comme demandé pour savoir s’ils sont OK avec les modifications en question et s’ils approuvent l’utilisation de la marque…
Et la réponse d’upstream est quasiment un ultimatum ???
Je ne jetterai pas la pierre à l’auteur du port. Franchement, après ça, que l’upstream aille se faire foutre.
[^] # Re: Impolitesse ?
Posté par liberforce (site web personnel) . Évalué à -3.
Faut pas faire du libre si on est trop susceptible. Un rappel de la licence n'est pas une lettre d'avocat. Si ton code est sur github, tu distribues tes sources puisque n'importe qui peut venir les cloner, work in progress ou pas.
Ce qui a manqué aux intervenants c'est ce morceau que j'aime dans le code of conduct de GNOME:
Celui qui ouvre le bug utilise des mots forts (will, must) parce que ce sont des obligations légales. C'est sûr, il aurait pu mettre des petites fleurs et des « s'il vous plaît », mais le fond aurait été le même. La réponse en mode « je te parle pas à toi » au lieu de mots d'explications n'est pas très constructive non plus.
Personnellement, je pense que sur ce genre de conflits il faut justement expliquer qu'on est de bonne foi et rester courtois. Rompre le dialogue au moindre pépin, ça ne mène nulle part (une exception : les personnes toxiques).
[^] # Re: Impolitesse ?
Posté par gouttegd . Évalué à 10.
Peut-être pas, mais quand l’empaqueteur manifeste dès le départ son intention de respecter la licence en contactant les développeurs upstream comme demandé par la licence, j’estime que le ton employé n’est pas du tout justifié.
Ici, les développeurs se sont immédiatement comportés comme si l’empaqueteur violait d’office la licence (d’où leur « rappel de la licence »).
Encore une fois, la bonne foi de l’empaqueteur est manifeste dans le message qu’il a laissé sur le forum du projet, quelques heures auparavant.
Ici, on a des développeurs qui exige qu’on leur demande leur accord (sur les choix de configuration effectués) avant de redistribuer leur logiciel sous son nom original, et qui se comportent comme des petits caïds en terrain conquis lorsqu’un empaqueteur les sollicite précisément pour ça.
Je suis peut-être trop susceptible, mais je maintiens que j’aurais réagi de la même façon que l’empaqueteur : ils peuvent se carrer leur logiciel où je pense.
[^] # Re: Impolitesse ?
Posté par Adrien . Évalué à 9.
Utiliser des versions « vanilla » présente rapidement une limite. En effet, si tu utilises plein de logiciels « vanilla » (libreoffice, thunderbird, firefox, pourquoi pas KDE ou Gnome, etc.), alors très rapidement tu va devoir gérer les mises à jour, la sécurité, les cassages non prévus, etc. toi-même.
Et c'est justement là qu'est l'intérêt de la distribution, notamment pour l'admin système : elle pré-mâche le travail.
Lorsque j'utilise le libreoffice de Debian, je sais que la sécurité est gérée, qu'ils n'y aura pas de modif qui vont tout casser au mauvais moment, etc. Prendre tout en vanilla revient à se passer de ce « prémachage », et rapidement ça devient infernal pour certaines personnes. Perso je ne vois pas mon beau-père devoir gérer tout un tas de truc en vanilla…
[^] # Re: Impolitesse ?
Posté par flagos . Évalué à 1. Dernière modification le 14 février 2018 à 14:12.
Je ne vois pas en quoi faire un apt upgrade sur un repo "vanilla" est plus risqué que faire le même apt upgrade sur les repo de la distrib.
[^] # Re: Impolitesse ?
Posté par claudex . Évalué à 6.
Parce que les repos de ta distrib (ici, on parle d'une distrib avec un cycle de release comme Debian) ne vont pas changer de version majeure n'importe quand et droper le support d'un format de fichier que tu utilise par exemple.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Impolitesse ?
Posté par Adrien . Évalué à 5. Dernière modification le 14 février 2018 à 14:56.
J'ajouterais aussi que Debian fournit des outils qualités pour tous les paquets, voici quelques exemples :
Tu me diras libreoffice fournit déjà ces outils, certes. Mais Debian le fait pour tous les paquets, ce qui est quand même pratique pour les petits projets.
[^] # Re: Impolitesse ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Par défaut, Firefox et Thunderbird vanilla se mettent à jour automatiquement. Et pas besoin d'attendre que le paquet de la distro soit mis à jour par le mainteneur du paquet.
Tes arguments ne sont valables que pour les logiciels qui n'incluent pas de système de mise à jour, ou qui sont installés sans passer par un dépôt tiers.
Et pour les cassages, je ne vois pas en quoi un logiciel utilisateur va casser quoi que ce soit. Ok pour une lib vanilla ou un environnment comme KDE ou GNOME que l'on met à jour indépendement de la distro. Mais pour le reste… Comme je le disais dans un autre commentaire, chez moi le paquet libreoffice de la distro est instable, alors que le paquet vanilla fonctionne parfaitement.. Comme quoi..
[^] # Re: Impolitesse ?
Posté par Adrien . Évalué à 5. Dernière modification le 15 février 2018 à 15:35.
Quand je parlais mise à jour, je pensais plutôt à tout ce que ça engendre. Par exemple dans notre labo une montée de version firefox ou Java casse certaines applications… On peut aussi citer une mise à jour Windows 10 qui a cassé Kaspersky chez des collègues.
De même, il peut y avoir des problèmes de compatibilité à gérer. Exemple stupide : KeepassX ou Skrooge ont fait évolué leurs formats de fichers. Autre exemple : un fichier fait avec Matlab 2017b ne sera pas lisible avec la version 2016a…
Donc sans prévenir, tu peux te retrouver avec des fichiers illisible d'autres utilisateurs, qui eux n'ont pas forcément fait la mise à jour.
EDIT : j'ajoute au problème les changements d'interfaces, qui peuvent être assez perturbant pour les utilisateurs.
Après je suis tout à fait conscient que pour le bidouilleur, utiliser quelques paquets « vanilla » peut être une bonne solution dans certains cas.
# Mainteneur, Contributeur
Posté par Leniwce . Évalué à -2. Dernière modification le 14 février 2018 à 13:16.
Mainteneur: Dans le logiciel libre, un mainteneur est le contributeur principal d'un logiciel. C'est celui qui est chargé de faire évoluer le logiciel, de corriger les bogues, d'accepter les correctifs proposés par d'autres contributeurs.
Contributeur: Les contributions possibles sont très variées et peuvent prendre la forme de: code source, tests (écriture et exécution), rapport de bogues, suggestion de nouvelles fonctionnalités, documentation, traductions (localisation (informatique) et traduction de la documentation), travail sur la procédure d'installation du logiciel, marketing, etc…
Source wiki
En resume l'equipe en charge de la distribution sont les mainteneurs de cette distribution, mais les contributeurs des logiciels qu'ils integrent a cette distribution. Il arrive cependant quelques fois que le mainteneur d'une distribution soit aussi le mainteneur du logiciel distribue au sein de la distribution.
-
Quand a la reponse type du developpeur "I will not be as educational next time", j'ai compris maintenant que ces personnes en dehors de leurs aptitudes bien ciblees sont des ignorants arrogants incapables de communiquer dans un langage soutenu.
attention chérie ça va moinsser
[^] # Re: Mainteneur, Contributeur
Posté par Sylvain Colinet (site web personnel) . Évalué à 4.
Oui c'est l'un des problèmes majeurs de cette histoire. Les développeurs de Pale Moon aurait du documenter comment eux attendent que leur logiciel soit construit, plutôt que de faire un appendum obscur à la licence MPL. C'est d'autant plus grave que le premier interlocuteur (le gars pédantique) a déjà rencontré ces problèmes de build mais au lieu de guider le mainteneur d'OpenBSD, il impose sa vision sans explication.
C'est pour moi une erreur de développeur débutant, qui compile son logiciel dans son environement et attend que les autres devine ce qu'il faut faire pour faire de même.
[^] # Re: Mainteneur, Contributeur
Posté par freem . Évalué à 6.
Je ne crois pas qu'il soit une cible de compilo, donc je pense que pédant suffira :)
# .
Posté par Sufflope (site web personnel) . Évalué à -10.
C'est toujours délicat de parler de ce qu'on ne connait pas, on est pas à l'abri de raconter des conneries.
[^] # Re: .
Posté par Kalenx . Évalué à 10.
Merci beaucoup de ta contribution. Elle illustre à merveille le point qui achoppe dans la réaction des développeurs de Pale Moon.
Même si tu as raison (et, précisons-le, je ne crois pas que ce soit le cas, je crois que tu as suranalysé 10 mots sur un journal de 3 pages), quel résultat penses-tu obtenir avec ce genre de message? Une discussion franche et ouverte sur le sujet? Une rétractation de ma part? Une épiphanie de la part de tous les lecteurs qui vont soudainement réaliser à quel point ce journal est inutile?
Si tu souhaites engendrer une réaction pour améliorer une situation qui te semble problématique (dans ce cas, mon imbécillité, dans le cas du journal, une infraction à leur propriété intellectuelle), es-tu conscient que tu viens de t'assurer de la meilleure des manières qu'une telle réaction n'aura jamais lieu, ni de ma part, ni des autres?
[^] # Re: .
Posté par Guillaume Knispel . Évalué à 10.
J'attends avec impatience la brillante démonstration probablement ultra pédante que tu vas nous faire pour appuyer tes propos…
(ouai mon commentaire est aussi vide que le tient, c'est voulu, assumé, car je suis relativement sûr de moi sur le fait que tu dis de la merde et que le ridicule te guette—frappe préemptive; tu nous épargnera une pirouette du style "oh, mais ya plein d'API systèmes que tout le monde réutilise sans les redistribuer", c'est pas de ça qu'on parle)
[^] # Re: .
Posté par xcomcmdr . Évalué à 3. Dernière modification le 15 février 2018 à 17:39.
Ben, c'est factuellement faux.
Beaucoup de logiciels utilisent le .NET Framework (2.0, 4.0, 4.5, 4.6, 4.7, à ce jour), DirectX (1/2/4/5/6/7/8/9/10/11/12), le runtime MSVC (beaucoup trop de versions), les API du kernel (kernel32, …), les API de User32.dll (du genre LoadIcon, ou pour lire/écrire dans le presse-papier, parmi beaucoup d'autres fonctions), et j'en passe.
Il y a-t-il une copie des bibliothèques de ces composants dans le dossier d'installation de l'application ?
Euh, non. Jamais.
Donc dire "chaque logiciel embarque justement ses propres versions de chaque librairie", c'est méconnaître Windows.
Dans le dossier d'installation, on met les bibliothèques qu'on ne veut pas partager avec le système, c'tout.
Mais celles qui font partie de Windows et que tout le monde utilise, on ne les met pas dans le dossier du programme (Runtime MSVC, kernel, … voir plus haut), ce serait la folie.
Regardons par exemple Notepad++ :
Que des DLL qui lui sont propre, et c'est normal.
On pourrait en mettre certaines dans le dossier système, mais pour 7 Mo de bibliothèque (donc 4 pour la libxml, et 1,2 Mo pour libiconv), on va pas se rajouter des problèmes de partage/mise à jour de bibliothèques partagées, tout ça pour économiser trois fois rien et termes d'espace disque.
Si on a un besoin absolu de partager des bibliothèques au niveau du système, il y a :
- .NET, où ce problème est réglé depuis le début (on met ça dans le GAC et c'est marre)
- OU (pour le code natif), on peut utiliser le Side-by-Side Assemblies :
https://msdn.microsoft.com/fr-fr/library/windows/desktop/ff951640(v=vs.85).aspx
Comme l'a fait Microsoft pour assurer la rétrocompatibilité :
https://blogs.msdn.microsoft.com/oldnewthing/20080129-00/?p=23663/
Il faut aussi distinguer les installeurs embarquant un programme d'installation d'une variante de DirectX / MSVC / .NET, qui selon la version de Windows cible, ne sont pas forcément installés.
Ces installeurs sont des exécutables librement distribuables fournies par Microsoft, qui ne font que d'installer ces éléments au niveau du système, pas du programme.
Windows XP par exemple n'inclut pas par défaut aucun élément .NET.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: .
Posté par gouttegd . Évalué à 10.
Euh, je ne sais pas pour NppShell et SciLexer, mais aucune des autres bibliothèques n’est propre à Notepad++.
C’est bien ce que disait l’auteur du journal : il est courant sous Windows qu’un programme embarque les bibliothèques dont il dépend, au lieu de se reposer sur les versions fournies par le système.
Ne serait-ce que parce que souvent, ces bibliothèques (comme libxml ou libcurl) ne sont mêmes pas fournies de base par le système, alors qu’elles font presque toujours partie d’une installation standard de presque n’importe quelle distribution GNU/Linux.
[^] # Re: .
Posté par xcomcmdr . Évalué à -2. Dernière modification le 15 février 2018 à 19:38.
C'était à prendre au sens "ce n'est pas MVCRT / DirectX / .NET / KERNEL32", bref un bidule Microsoft Windows. :p
Je sais bien que la libxml n'est pas propre à Notepad++.
Pour autant, partager la libxml de Notepad++ au niveau du système, c'est d'un intérêt limité.
Exactement, c'est même pas fourni par Windows, donc que je sois dans le dossier du programme ne me choque pas du tout.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: .
Posté par Adrien . Évalué à 6.
Tu veux dire qu'il est normal de mettre à jour Notepad++ une petite dizaine de fois par an, simplement pour suivre les mises à jour de sécurité de libxml ou curl ?
https://security-tracker.debian.org/tracker/source-package/libxml2
https://security-tracker.debian.org/tracker/source-package/curl
[^] # Re: .
Posté par xcomcmdr . Évalué à 1. Dernière modification le 15 février 2018 à 21:50.
… Oui ? Ça prend 30 secondes ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: .
Posté par groumly . Évalué à -6.
Si ça évite le merdier sans nom qu’est le packaging sous Linux, ca me paraît mieux wue l’altermative, oui.
On est plus en 1997, c’est raisonnable de partir du principe que l’est postes sont connectés en permanence, et les systèmes de mise à jour automatique fonctionnent bien.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: .
Posté par Adrien . Évalué à 10.
La dernière version de Notepad++ date du 1 janvier 2018. Or il y a déjà eu 2 failles de sécurité sur libcurl sorties fin janvier…
Votre solution consiste donc à laisser des failles de sécurités, en attendant la prochaine release ? Et bien perso je préfère la solution du packaging, qui a permis de corriger ces failles plus rapidement, et de manière plus systématique.
[^] # Re: .
Posté par totof2000 . Évalué à 4.
Non, ce n'est pas raisonnable: dans le cas de l'utilisation d'un ordinateur portable par exemple, il est fort possible qu'on se retrouve à un moment ou à un autre sans connection. Sinon, considérer qu'une mise à jour se passera bien est également une erreur: encore aujourd'hui, ça ne se passe pas toujours correctement : que ce soit sous Linux ou sous Windows, il y a encore trop de problèmes.
[^] # Re: .
Posté par groumly . Évalué à -3.
Et tes mises à jours systèmes, tu les installes comment alors? Avec un DVD?
Des mises à jour systèmes, oui, surtout si ton système s’amuse à packager la moitié de la planète en shared. Si tu te contentes de mettre à jour un binaire “self contained”, je vois vraiment pas ce qui peut peter. Apple et android distribuent des milliards de mises à jour de cette façon chaque année et ça pete très rarement (moins souvent que le joyeux pot de pus qu’est le packaging sous Linux en tout cas).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: .
Posté par Kalenx . Évalué à 10.
Ce qui est bien avec ces points de vue réfléchis et argumentés, c'est qu'ils font avancer la discussion de manière constructive et respectueuse.
[^] # Re: .
Posté par totof2000 . Évalué à 4.
Mon premier réflexe pour te répondre serait de te dire "pauvre c**" et de clore la conversation, vu que tu ne sais même pas ce que tu écris et que tu réponds n'importe quoi.
Relis bien ce que j'ai écrit et ce à quoi tu réponds: je réagis sur connecté en permanence, ce qui est bien souvent faux pour un ordinateur portable. De plius, quand ces appareils sont connectés, il faut considérer dans le processus de mise à jour que la connection peut être de mauvaise qualité. Ca devrait influencer la façon dont les mises à jour sont proposées/téléchargées/effectuées (du style toujours demander avant de mettre à jour, ne pas forcer la main de l'utilisateur pour qu'i décide lui-même de ce qu'il fera).
C'est pas parce que tu ne vois pas ce qui peut arriver que ça n'arrivera pas (un exemple tout bête : la mise à jour en elle-même peut fonctionner mais les données ou la configuration devenir inutilisable, donc faut tout refaire, et c'est toujours au moment ou tu n'as pas le temps que ça arrive). Certes, tu n'impacte pas l'ensemble de la machine, mais si ça se asse au moment ou tu as besoin dudit soft, c'est pareil.
Je ne sais pas pour Apple mais ça m'arrive de temps en tempos sur Android de devoir faire une désinstallation/réinstallation d'un soft suite à une mise à jour parce qu'il ne fonctionne plus, et là je dois tout refaire les conf/personnalisation.
Ben pour ma part, j'ai pas trop de problèmes avec Ubuntu (du moins pas plus qu'avec un Windows par exemple) : en général ça passe. Monb épouse fait ellle-même les mises à jour système sans que je n'y touche. Les seules fois ou j'ai eu des problèmes c'est pour certains softs hors dépot de la distribution (plugin flash par exemple) qui ont bloqué certaines mises à jour. J'ai de moins bon souvenirs avec Arch Linux par exemple.
Note qu'ici, je ne parle pas de montée de version (passage 14.04 vers 16.04 par exemplke) ou là j'ai eu quelques soucis qu'il a fallu que je rattrappe manuellement.
[^] # Re: .
Posté par Kalenx . Évalué à 6.
La réponse de gouttegd est déjà très claire, mais histoire de renchérir :
Ce sont toutes des librairies liées à Windows ou, du moins, développées par Microsoft. Qt est très utilisé, même sur Windows, mais tu ne le verras pas dans system32…
Quand je parlais d'interpréter 10 mots hors contexte dans un journal de 3 pages, c'était ça. Si mon journal portait entièrement là-dessus, bien sûr que j'aurais pu apporter des précisions, mais dans le contexte, je les estimais inutiles. Peut-être me suis-je trompé.
[^] # Re: .
Posté par PLuG . Évalué à 7.
l'intéret de la mise en commun, c'est justement la gestion commune des correctifs.
Lors des bugs de sécurité sur la bibliotheque ssl ou zlib, il a fallu relivrer l'intégralité des logiciels les utilisant … et sur un système on n'est jamais sûr que l'ensemble des mainteneurs/éditeurs ont bien identifié qu'ils devaient relivrer.
Avec de vraies DLL partagées ce soucis est règlé de facto. Et si on a besoin de versions différentes de ces DLL il suffit de les faire cohabiter.
Le second point interessant, ce n'est pas l'économie de place disque, sauf peut-être dans l'embarqué, mais bien l'économie de mémoire. Avec des DLL en commun le système d'exploitation ne monte les pages de code qu'une seule fois en ram …
mes 2c
[^] # Re: .
Posté par kna . Évalué à 7.
D'autant que mettre à jour tous les softs à chaque fois, ça t'incite à faire de la place.
[^] # Re: .
Posté par Raphaël G. (site web personnel) . Évalué à 0.
Sous windows, ça choque personne la place disque bouffée par toutes les versions du framework .Net, directX et consort ?
Pour avoir voulu toucher un peu au monde du dev sous windows, c'est juste un enfer sans nom…
Sous un linux, tu vas installer les paquets lib64xyz-devel, la lib64xyzXYZ qui va avec, tu compiles et c'est mare.
Et le pire c'est que les librairies de développements ne sont pas les mêmes que celles redistribuables.
Donc si tu fais pas attention tu te retrouves avec des dépendances sur les version debug des dll, qui sont pas disponibles sans installer des Go de l'environnement de développement. Et le pire dans tout ça c'est le packaging des derniers compilateurs MSVC qui forcent à installer tout l'environnement de développement.
Au final ça m'a pris moins de place de monter une vm virtualbox, un environnement de développement linux complet que d'installer l'environnement sur windows…
[^] # Re: .
Posté par xcomcmdr . Évalué à 2. Dernière modification le 15 mars 2018 à 08:11.
Ben non, c'est très léger. Tu sais de nos jours, le moindre film en HD est bien plus gros qu'une installation de Windows. Et puis bon, compter les Mo/Go en 2018, c'est d'une parfaite inutilité.
Mauvais dév, changer dév. Les logiciels que tu déploies sont compilés en mode Release, pas en mode Debug.
Quand tu installe Visual Studio, tu peux choisir quels éléments installer. Si tu ne prends que ce qui t’intéresse, ça devrait être nettement moins long.
Et puis bon, tu compares un environnement de développement intégré à des fichiers d'en-têtre + compilateur + linker seuls, évidemment que l'un va être plus lourd que l'autre…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.