«je ne pars pas du principe que libre = gratuit et GPL = payant...»
Non, mais tu raisonnes comme si libre == gratuit, et non-libre == payant. Même si tu es conscient de la différence, tu suis ton raisonnement comme si c'était le cas.
«mais je t'en prie cite moi des exemples de grosses boites ayant des produits sous GPL et qui ne vie que grave à la vente de ces produits»
Ça fait beaucoup de contraintes concernant les exemples que je peux te donner, dis moi. Moi j'ai des exemples (et encore, il me faudrait du temps pour les retrouver vu que ce n'est pas mon domaine) de boîtes pas grosses, qui vendent des logiciels spécialisés sous GPL, qui ne sont pas en téléchargement sur leur site, et qui sont plutôt chers.
Si ça te convient comme type d'exemples, je ferai l'effort de rechercher, je sais que j'en avais trouvé une suite à un message sur le newsgroup de "debats" sur linux :-)
Ceci dit, je serais tenté de dire que si une boîte n'arrive pas à vivre uniquement de la vente de produits, il y a deux manières de voir le problème:
- soit le libre n'est pas quelque chose que les clients devraient vouloir.
- soit les boîtes doivent s'adapter à la demande et trouver un moyen de vivre tout en proposant ce que les clients veulent. Celles qui ne savent pas s'adapter disparaissent. C'est très ultra-libéral comme point de vue, mais je préfère encore ça à la première solution.
«vu que le compilo t'es fourni, si sun fait faillite demain, explique moi ce qui t'empeche de continuer à utiliser ton compilo»
Je n'ai jamais prétendu que si la boîte coule tu ne peux plus utiliser ses produits. Si MS coule tu peux toujours continuer à utiliser Word. Par contre les produits n'évolueront plus, ce qui fait qu'en quelques années ils seront devenus obsolètes.
«voir d'en créer un from scratch étant donné que les specs de java sont publiques...»
Ah ben voilà, quand un soft n'est pas libre, on peut être ammené à le redévelopper parce qu'on n'a pas les sources. Super. Si j'étais un décideur pressé, je ne prendrais certainement pas ce risque.
«pour les programmeurs, t de mauvaise foi»
Dis donc c'est un peu facile, quand la réponse ne te plait pas c'est qu'on est de mauvaise foi ?
Tu dis qu'avec le libre le nom des programmeurs n'est pas associé à leur code, alors que c'est justement avec le propriétaire que c'est le cas. Je me contentais de comparer le nombre de développeur qu'on connaissait à la fois dans le libre et le proprio. Bien évidemment qu'on ne connaît pas tous les développeurs. Par contre dans tout projet correctement géré on peut retrouver leurs noms.
«par ailleurs les produits ms c pas forcément le meilleur exemple, y'en a plein le MSDN, et via les easters eggs de programmes, on peut les voir...»
Si j'avais été de mauvaise foi comme tu dis, j'aurais peut-être choisi le "meilleur exemple" pour défendre mon point de vue. Mais je ne met pas en question le fait qu'on puisse retrouver le nom des développeurs, juste le fait que quand on fait du libre on a plus de chances d'etre connu du public.
«espérez un monde 100% libre et mal organisé»
Tu serais pas un tout petit peu manichéen des fois ?
Toi ton point de vue c'est que tout le libre devrait utiliser une solution propriétaire, et quand on n'est pas d'accord, c'est qu'on espère l'extinction totale du propriétaire dans l'univers ? Wahou :-)
Moi j'estime juste que pour mes besoins, et ceux d'une entreprise si jamais j'en ai la charge un jour, le propriétaire n'est pas satisfaisant. Du point de vue du client. Que les producteurs se débrouillent comme ils le désirent pour me procurer les produits que je désire acheter, ce n'est pas mon boulot.
PS: je tiens à m'excuser auprès de mes lecteurs pour cet argumentaire Orienté Pognon, mais c'est sur ce terrain que le monsieur a voulu discuter, alors..
Je ne connaissait pas (http://groovy.codehaus.org/(...)), mais ça a l'air sympa. Ceci dit, ça concerne la plateforme Java, et non le langage Java, si j'ai bien compris. Or là je trollais allègrement sur le langage :-)
Moi j'suis un Ruby-man (pfiou, pendant un moment, j'ai cru qeu j'étais un rugbyman), et comme Ruby sait bien s'introspecter je me suis demandé si on pouvait faire de la programmation orientée aspect avec. Je suis donc tombé sur ça: http://aspectr.sourceforge.net/(...)
Maintenant, je n'ai plus qu'à comprendre à quoi sert la programmation orientée aspect :-)
(Ruby, le vrai Java Killer... À vos lance-flammes...)
Attention, tu n'as pas compris de quoi on parle, alors forcément que tu t'énnerves. Le libre peut être commercial, et le non-libre peut être gratuit, ce sont deux choses qui n'ont pas de rapport. Si tu pars du principe que libre == gratuit et non-libre == payant, forcément il y a un (gros) malentendu.
«on voit que des prises de tete sur quoi est 100% libre, sans se demander quelle était la finalité...»
Ne pas s'interroger sur l'ouverture du code, c'est raisonner à court terme... ce que tu sembles pourtant "nous" reprocher. Du code ouvert et libre, ça signifie que quoi qu'il arrive, on pourra toujours apporter des modifications aux produits qu'on a acheté, c'est un aspect qui devrait être au coeur des préoccupations des entreprises.
Du code fermé, par contre, c'est se rendre dépendant d'une entreprise. Si elle survit tant mieux, sinon il faut acheter un nouveau produit.
Voilà une raison OP (Orientée Pognon) de préférer des produits libres à des produits propriétaires. Histoire de (tenter de) te convaincre que les gens qui s'intéressent à l'aspect libre ne sont pas tous des crétins profonds.
«Je trouve légitime que des programmeurs veuillent se faire rétribuer pour leur travail...soit en demandant de l'argent, soit en veillant à ce que son nom soit attaché au code...ce que la GPL ne permet pas»
L'as-tu lue, la GPL ? Ok, tu n'es pas d'accord sur le fait que l'on peut être payé et développer du GPL, c'est ton droit de nier les exemples existant. Mais sur le deuxième point, c'est n'importe quoi. Tu confonds allègrement logiciel libre et domaine public. La GPL conserve évidemment le copyright des auteurs sur leur code.
Tu n'as pas l'impression que le nom des développeurs est associé à leur code ? Bien, je suis sûr que tu peux citer de mémoire, comme beaucoup de gens ici, le nom de quelques développeurs du noyau Linux. Peux-tu faire de même pour les développeurs de Windows ?
Autres gens connus, le développeur d'Emacs, celui de Python, celui de Perl. Connais-tu des développeurs de Visual Basic, d'ASP, de Visual Studio ? (exemples pris au hasard, de logiciels propriétaires en général)
Je ne lui reproche rien, je me moque car il pose une question pour mettre en défaut son interlocuteur (t'es pas cap' de me donner un exemple), et quand on lui repose la même question un peu après, il donne des exemples. Or il s'était servi du manque d'exemples pour ne pas répondre.
Vu le smiley je suppose qu'il s'en est rendu compte, mais ça montre bien qu'il esquive les questions alors qu'il pourrait y répondre.
J'ai pas dit que c'était adapté dans tous les cas, juste dans le cas dont je parle :-)
Il s'agissait d'un type qui voulait que "les gens" l'aident à faire ses gros calculs, en faisant tourner une appli en tâche de fond pendant un mois. Une sorte de Seti@Home en moins distribué.
Sachant que pour avoir un maximum de contributeurs il faut un truc portable et simple à installer, et sachant qu'il ne doit pas être un informaticien professionnel, Java est une solution adaptée. D'autant plus que sa lenteur ne sera pas pénalisante, car sur un calcul d'un mois, les parties lourdes seront compilées par le JIT.
Donc pour moi, c'était un choix correct. Je précise d'ailleurs qu'il s'agit de la plateforme Java, pas le langage, car il peut très bien avoir codé le tout en ADA, et compilé pour une JVM, par exemple.
Oui, mais avec du script on en revient à ce qu'on disait plus haut: ces fonctionnalités viennent avec l'interprétation. Et quand un langage est compilé, on contourne le problème en rajoutant un interpréteur dedans (ou un compilateur).
«As-tu déjà utilisé récemment depuis le jdk 1.4 des GUI développés en SWING (j'insiste par rapport au FUD SWT c'est génial / SWING de la daube).»
Moi oui, et sincèrement, SWING c'est de la daube. Ça rame sur un portable que j'ai acheté en septembre 2003, c'est inadmissible et ça donne une mauvaise image de Java qui n'est pas si lent que ça en réalité. C'est ce qui fait que sur slashdot hier des gens critiquaient l'utilisation de Java pour faire des calculs scientifiques distribués, alors qu'en fait c'était un choix parfaitement adapté.
Certes, c'est moins lent qu'avant, mais quand je vois un programme tout simple qui rame sur une machine que je trouve trop puissante pour ce que j'en fais, non merci.
(Si je dis ça, ce n'est pas pour troller sur Java, j'aurais de bien meilleures pistes de trolls à ce sujet hein :-)
Moi je connais des libs qui permettent de générer du code à la volée, et de faire au final ce dont je parlais plus haut, mais c'est dépendant de la machine et pas pratique du tout.
S'il y a d'autres solutions ça m'intéresse, car je ne vois absolument pas comment on peut, sans compiler et sans interpréter, exécuter du code que l'on ne connait pas au moment de la production du logiciel :-)
Après, pour ce qui est de faire des inclusions conditionnelles de code à coups de bibliothèques dynamiques ok, mais c'est moins puissant que ce que je décrivais.
«Donc, pour vous (/toi), un langage de haut niveau, ce serait un langage faiblement typé ou réflexif, par exemple?»
C'est juste des exemples de ce qu'on trouve parmi les langages dits de "haut niveau", que je trouvais assez représentatifs concernant la différence interpretation/compilation.
Pour l'indépendance par rapport au matériel, par exemple, l'interprétation est aussi une bonne solution. D'ailleurs si Java est indépendant de la machine c'est en partie parce qu'il est interprété (au niveau du bytecode), ce qui simplifie bien la vie.
(Je précise avant qu'on me tombe dessus que l'indépendance par rapport au matériel peut aussi se faire via une bibliothèque bien foutue, mais dans ce cas là ça n'est plus un caractère inhérent au langage.)
«[...] on dit souvent que c'est une fonctionnalité nécessaire. Ce qui m'étonne dans ce discours, c'est que la réflexivité n'est qu'une technique, qu'un moyen. [...] »
Oula, tu t'embarques bien loin à répondre à des objections que personne n'a formulé ici :-)
Pour moi la réflexivité et le changement du code à l'exécution c'est un truc pratique, et ça fait partie de ce que j'aime avoir à disposition, c'est tout. Or c'est infiniment plus facile à faire en interprété qu'en compilé.
«f_luke : Est-ce qu'une stratégie de standard propriétaire est tenable à long terme par rapport à une stratégie de standard ouvert ?
Quel standard propriétaire ? Pouvez-vous me donner le nom d'un standard ouvert significatif qui ne serait pas supporté par la plate-forme Microsoft ?
Boo : Compte tenu de ce que vous dites de la force de Windows, pensez-vous que Windows est menacé par Linux ?
La question est un peu trop vaste :-) ! Linux est une réalité sur les serveurs, mais prend surtout des parts de marché à Unix. La concurrence est saine et nous permet de nous améliorer !
_megamoule : Pouvez-vous me donner le nom d'un standard ouvert significatif qui ne serait pas supporté par la plate-forme Microsoft ?
Un exemple parmi d'autres: c'est plus facile d'avoir un langage faiblement type quand il est interprété. Ou d'avoir un langage réflexif et dans lequel tu peux changer des bouts de code à l'exécutions.
En C/C++, pour ce dernier point, je suppose qu'il faut recompiler à la volée, et c'est pas terrible.
«pour être confort, il faut 512 Mo pour faire du Java»
C'est pas spécialement vrai, mon portable ne possède que 256 Mo de RAM, et je pourrais utiliser des logiciels faits en Java.
Ceci dit je trouve ça assez inquiétant que pour toi le libre doive remonter la barre des exigeances techniques à 512 Mo. Il y a des tonnes d'applications où ce n'est pas envisageable, et tout le monde ne peut pas se procurer une machine dernier cri. À moins d'exclure les pays du Sud, on va se trainer des PII pendant au moins dix ans encore.
«il y a même des gens pour dire que des langages interprétés sont bien car ils sont encore plus haut niveau que Java»
Oui, clairement. Si tu as eu une telle révélation avec Java, essaye le Ruby ou le Python, tu verras que c'est beaucoup plus agréable que du Java, et que la plupart du temps la rapidité est au rendez-vous.
T'es en train de nous dire que la seule solution c'est de faire du libre à base de non-libre. Bon ben si le libre n'est pas viable en lui même, c'est pas la peine, on arrête tout de suite et on fait du freeware.
L'argument est boîteux, de prétendre que la liberté c'est de savoir incorporer les trucs non-libres. Un truc non-libre, c'est pas libre, même si c'est gratuit et vachement bien (au passage, on pourrait débattre de la qualité de Java par rapport à certaines solutions libre, hein :-).
Au hasard: Delphi c'est pas libre, donc il semble difficile de contribuer à ce projet en utilisant des LL.
Mais bon de toutes façons Windows c'est pas libre, alors c'est un peu chipotter. Et histoire de finir sur un lancement de débat: vous pensez que c'est bien pour le libre de corriger un des plus gros problèmes de Windows, à savoir la gestion de paquets ? :-)
Oui, mais il y a un autre problème, c'est que ça valide ton email auprès des spammers. Donc certes tu ne vois pas les spams, mais le débit ne diminue pas. Et, beaucoup plus grave, plus il y a d'adresses validées plus une base d'adresses se vend cher, donc ça contribue à augmenter l'intérêt de faire du spam.
Mais... bogofilter ça marche bien, vous ne trouvez pas ? Ça en laisse passer un peu, mais c'est moins lourd pour les gens qui t'écrivent et ça ne valide pas l'adresse.
«Je demande a voir la coherence de ton systeme apres plusieurs actions comme celle-ci. »
Là excuse moi mais c'est du foutage de gueule, un peu =)
Tu vantes les systèmes sans gestion de dépendances, et quand on te montre comment faire ça avec des RPMS, tu dis que le système risque de ne pas être cohérent...
La DB est nécessaire uniquement pour garder la liste des paquets installés, dans ce cas. De mémoire, il me semble que Slack se souvient aussi de la base des paquets installés.
«Comme X quand tu installes Emacs (ah non, c'est Debian, ca) ?»
«Donc ca depend de la qualite des dependances ? C'est pas tres rassurant de savoir qu'une dependance ne peut pas etre parfaite et pour le coup c'est un tres bon argument contre son utilisation.»
Je suppose que tu voulais dire "peut ne pas etre parfaite", et je répondrais en ce sens: une dépendance peut ne pas être parfaite comme un logiciel peut ne pas être parfait. Je ne me refuse pas le droit d'utiliser des logiciels faits par d'autres sous prétexte qu'ils peuvent ne pas être parfaits. Idem pour les paquets avec gestion des dépendances.
D'autant plus qu'une dépendance foireuse est presque sans conséquences. Au pire ça installe des choses en trop, sinon tu dois installer la dépendance toi même (comme avec un système sans gestion des dépendances donc).
Si on était constamment confrontés à des paquets foireux qui refusent de s'installer à tort, je ne dis pas, mais j'ai dû rencontrer un paquet foireux en deux ans d'utilisation de Debian unstable. Comparé au temps que j'ai gagné à ne pas aller télécharger tous les paquets à la main...
Ah mince, moi à la lecture il m'avait semblé voir une question plutôt qu'une affirmation. Étonnant que tu confondes, tu sembles bien calé niveau affirmations.
«qui montre une meconnaissance assez eleve du systeme»
Amusant de voir à quel point le bas niveau de tes interlocuteurs te permet d'éviter de répondre :-)
«Chose que bien entendu, on fait tout les jours en temps limite»
Sous prétexte que les tâches d'administration ne se font pas tous les jours, on devrait les rendre plus fastidieuses ? Je ne pense pas.
Effectivement ce que dit le monsieur au dessus est pertinent. Tu me disais ailleurs que je devais pouvoir mémoriser moi même les dépendances entre logiciels (ne pas effacer telle lib si elle est requise ailleurs), car il faut "savoir ce qu'on fait". Mais si tu administres un paquet de machines différentes, tu dois aussi tout mémoriser pour chacune d'entre elles ? Savoir que la libtruc est requise sur la machine 42, mais pas sur la machine 36 ?
«Et bien si tu connais effectivement ce que c'est, tu n'as pas besoin de connaitre autre chose. »
C'est profondément ridicule. Je sais très bien à quoi sert libxml1, en quoi est-ce que ça me permet de savoir si j'ai des logiciels qui l'utilisent ?
J'ai environ 1500 paquets installés sur ma machine perso, je suis censé me souvenir des dépe^Wbibliothèques utilisées par chacun d'entre eux ? Non merci :-)
«C'est vrai que si tu as une distrib avec 2000 paquets d'installe, tu ne dois pas etre habituer a voir les choses simplement.»
Si pour toi, voir les choses simplement, c'est savoir ce que chaque programme utilise comme bibliothèques, je ne vois certainement pas les choses simplement :-)
«S'il-te-plait, arrete d'ecrire que je trouve les dependances inutiles.»
Moi c'est l'impression que me laisse ton post même après re(re)lecture.
«Tu m'accuses de parti pris, apparemment.»
Non je t'accuse de raconter n'importe quoi, c'est pas pareil. Tu peux très bien être convaincu du bien fondé de tes arguments :-)
«Ah bah si on peut alors, le monde est sauve. Montre moi un exemple pour voir ce que ca donne en pratique.»
Et voilà, la dérision pour contourner l'argument, merci pour cet exemple de rigueur.
Remise dans le contexte: tu reproches que certaines dépendances ne sont pas requises, car le logiciel fonctionne sans. Je te dis qu'effectivement, on peut définir des dépendances non-requises, sans lesquelles le logiciel s'installe et fonctionne. En effet, "le monde est sauvé", ton problème n'en est pas un. Qu'est-ce que tu ne comprends pas là dedans ?
Je te donne un exemple que j'ai rencontré hier, puisque c'est trop abstrait: si tu installes libsoap-ruby, tu obtiens de quoi faire du SOAP en ruby. Cette bibliothèque n'exige pas que tu possèdes webrick (une bibli pour faire un serveur web en ruby), mais si tu la possèdes, alors tu as accès à plus de fonctions de libsoap-ruby.
C'est bien ce dont tu parlais non ?
«Je confirme que fractionner les paquets, a cause des dependances, pose plus de probleme qu'autre chose.»
Je confirme le contraire, et on est bien avancés...
«C'est plus simple ?»
Oui, sauf si tu t'amuses à faire la gestion des dépendances à la main. N'importe quel système bien foutu les gère à ta place, et donc installe ce dont le paquet a besoin. Pas de "ça marche pas, il faut libtruc-machin" si les paquets sont bien faits (et ils doivent l'être vu que je n'ai pas encore eu de problèmes depuis que j'utilise ma debian).
«Hors-sujet»
Certainement pas, analogie. Ton système de fichier est une base de données, s'il casse tu es mal. Un système de gestion de paquets utilise une base de données, s'il casse tu es mal (mais beaucoup moins).
En suivant ton raisonnement, il est dangereux d'utiliser un système de fichier. C'est absurde donc ton raisonnement est faux.
Si c'est moi qui me trompe, merci de m'expliquer pourquoi avec autre chose qu'un Hors-sujet.
«Tu es serieux ? Parce que la ta credibilite vient d'en prendre un coup.»
Tout à fait. Si les bases RPM plantent c'est dommage (jamais vu, mais je fais confiance à google), par contre ta généralisation est abusive. Partir d'un exemple d'un truc foireux pour démontrer que tout est foireux, c'est comme dire que l'informatique ça plante parce que Windows ça plante.
Il y a des tas d'application qui utilisent des bases de données et qui ont besoin de fiabilité, alors si tu peux démontrer que les BdD c'est pas fiable, tu vas révolutionner l'industrie de l'informatique, je tiens à te prévenir :-)
Le truc que tu as coupé dans ce que je dis, c'est aussi qu'un plantage de la BdD de gestion des paquets, ça ne casse pas le système. Ça peut être assez lourd à reconstruire, mais le système continue de tourner sans s'en préoccuper. C'est juste genant quand tu veux installer un nouveau paquet. Alors qu'un plantage de la base de registres de Windows, c'est le système qui ne boot plus.
«Peut-on installer une distrib RPM sans la DB ?»
Je ne vois pas l'intérêt, mais oui, un RPM ce n'est qu'un paquet semblable à ceux de Slack avec en plus des infos de dépendances. Déjà, si tu n'aimes pas les dépendances, tu peux forcer l'installation sans vérification. Ensuite, si tu n'aimes pas la BdD tu peux utiliser le RPM comme un .tar.gz, mais ça ne sert à rien. Autant prendre les .tar.gz.
«ca ne me semble pas terrible de desinstaller un package sans savoir ce que c'est»
Tu peux savoir ce que c'est sans savoir si un logiciel installé en a besoin. Par exemple j'ai libxml1 et libxml2, je sais très bien ce que c'est, mais comment savoir si j'ai des logiciels qui utilisent libxml1 ?
Je pourrais, effectivement, compter sur ma mémoire, mais je préfère laisser l'ordinateur faire ça, perso...
«ce ne sont pas les dependances qui font forcement la necessite d'un logiciel»
Les dépendances ne résolvent pas tous les problèmes, donc elles ne servent à rien ?
«D'autre part, les gestions sont souvent mal ficelees avec les rpms ou deb.»
C'est idiot comme argument. Pour montrer que les dépendances sont inutiles, tu expliques qu'elles sont mal faites. Donc si elles étaient bien faites, elles seraient utiles ?
«Ce n'est pas parce qu'un logiciel A a une dependance avec B qu'il ne va plus marcher du tout si je retire B. Dans la plupart des cas, le logiciel marche, simplement avec une fonctionnalite en moins»
Sais-tu que l'on peut faire une distinction entre dépendances requises et optionelles ? Dans un paquet bien fait, si tu retires une dépendance requise, c'est cassé.
«Et si on a pas besoin des include ou des libs, et bien tant pis, tous le monde ne bosse pas sur de l'embarque ou des serveurs i486, il y a de la place sur les disques quand meme.»
"Moi j'installe tout, donc pas de problèmes de dépendances", ah ben oui, vu comme ça :-)
«Enfin, une base de donnee qui plante pose souvent de serieux problemes et met en jeux la sanite de tout le systeme. Je suis desole de choquer mais cela me semble tres similaire a la base de registre de Windows. Ca ne me semble pas solide comme methode.»
Mouahaha :-)
Les bases de données, c'est d'la merde, si ça plante c'est planté. Et ton système de fichier aussi, s'il plante tu es mal, vu que c'est une sorte de base de données. Le truc c'est que ça n'a quasiment aucune raison de planter, et que dans tous les cas la base de paquets peut être reconstruite.
Le défaut de la base de registres c'est que c'est un format obscur qui plante tout le temps et qui n'est jamais nettoyé. Rien à voir avec une vraie base de données bien gérée.
Là c'est plus les systemes de gestion de paquets que tu jettes à la poubelle, c'est tout ce qui utilise une BdD...
«Le systeme de la slack est honnetement le plus fiable a l'utilisation»
Pourquoi ?
(Je veux bien te croire, j'ai été utilisateur de Slackware, mais au moins explique pourquoi. Je considère que ton "incassable" n'est pas un argument vu que la base de paquets de slack c'est aussi une base de données :-)
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Yusei (Mastodon) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 2.
Non, mais tu raisonnes comme si libre == gratuit, et non-libre == payant. Même si tu es conscient de la différence, tu suis ton raisonnement comme si c'était le cas.
«mais je t'en prie cite moi des exemples de grosses boites ayant des produits sous GPL et qui ne vie que grave à la vente de ces produits»
Ça fait beaucoup de contraintes concernant les exemples que je peux te donner, dis moi. Moi j'ai des exemples (et encore, il me faudrait du temps pour les retrouver vu que ce n'est pas mon domaine) de boîtes pas grosses, qui vendent des logiciels spécialisés sous GPL, qui ne sont pas en téléchargement sur leur site, et qui sont plutôt chers.
Si ça te convient comme type d'exemples, je ferai l'effort de rechercher, je sais que j'en avais trouvé une suite à un message sur le newsgroup de "debats" sur linux :-)
Ceci dit, je serais tenté de dire que si une boîte n'arrive pas à vivre uniquement de la vente de produits, il y a deux manières de voir le problème:
- soit le libre n'est pas quelque chose que les clients devraient vouloir.
- soit les boîtes doivent s'adapter à la demande et trouver un moyen de vivre tout en proposant ce que les clients veulent. Celles qui ne savent pas s'adapter disparaissent. C'est très ultra-libéral comme point de vue, mais je préfère encore ça à la première solution.
«vu que le compilo t'es fourni, si sun fait faillite demain, explique moi ce qui t'empeche de continuer à utiliser ton compilo»
Je n'ai jamais prétendu que si la boîte coule tu ne peux plus utiliser ses produits. Si MS coule tu peux toujours continuer à utiliser Word. Par contre les produits n'évolueront plus, ce qui fait qu'en quelques années ils seront devenus obsolètes.
«voir d'en créer un from scratch étant donné que les specs de java sont publiques...»
Ah ben voilà, quand un soft n'est pas libre, on peut être ammené à le redévelopper parce qu'on n'a pas les sources. Super. Si j'étais un décideur pressé, je ne prendrais certainement pas ce risque.
«pour les programmeurs, t de mauvaise foi»
Dis donc c'est un peu facile, quand la réponse ne te plait pas c'est qu'on est de mauvaise foi ?
Tu dis qu'avec le libre le nom des programmeurs n'est pas associé à leur code, alors que c'est justement avec le propriétaire que c'est le cas. Je me contentais de comparer le nombre de développeur qu'on connaissait à la fois dans le libre et le proprio. Bien évidemment qu'on ne connaît pas tous les développeurs. Par contre dans tout projet correctement géré on peut retrouver leurs noms.
«par ailleurs les produits ms c pas forcément le meilleur exemple, y'en a plein le MSDN, et via les easters eggs de programmes, on peut les voir...»
Si j'avais été de mauvaise foi comme tu dis, j'aurais peut-être choisi le "meilleur exemple" pour défendre mon point de vue. Mais je ne met pas en question le fait qu'on puisse retrouver le nom des développeurs, juste le fait que quand on fait du libre on a plus de chances d'etre connu du public.
«espérez un monde 100% libre et mal organisé»
Tu serais pas un tout petit peu manichéen des fois ?
Toi ton point de vue c'est que tout le libre devrait utiliser une solution propriétaire, et quand on n'est pas d'accord, c'est qu'on espère l'extinction totale du propriétaire dans l'univers ? Wahou :-)
Moi j'estime juste que pour mes besoins, et ceux d'une entreprise si jamais j'en ai la charge un jour, le propriétaire n'est pas satisfaisant. Du point de vue du client. Que les producteurs se débrouillent comme ils le désirent pour me procurer les produits que je désire acheter, ce n'est pas mon boulot.
PS: je tiens à m'excuser auprès de mes lecteurs pour cet argumentaire Orienté Pognon, mais c'est sur ce terrain que le monsieur a voulu discuter, alors..
[^] # Re: Conférence à Paris : "Programmation orientée aspect en Java avec JAC"
Posté par Yusei (Mastodon) . En réponse à la dépêche Conférence à Paris : "Programmation orientée aspect en Java avec JAC". Évalué à 1.
[^] # Re: Conférence à Paris : "Programmation orientée aspect en Java avec JAC"
Posté par Yusei (Mastodon) . En réponse à la dépêche Conférence à Paris : "Programmation orientée aspect en Java avec JAC". Évalué à 3.
Maintenant, je n'ai plus qu'à comprendre à quoi sert la programmation orientée aspect :-)
(Ruby, le vrai Java Killer... À vos lance-flammes...)
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Yusei (Mastodon) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 3.
Attention, tu n'as pas compris de quoi on parle, alors forcément que tu t'énnerves. Le libre peut être commercial, et le non-libre peut être gratuit, ce sont deux choses qui n'ont pas de rapport. Si tu pars du principe que libre == gratuit et non-libre == payant, forcément il y a un (gros) malentendu.
«on voit que des prises de tete sur quoi est 100% libre, sans se demander quelle était la finalité...»
Ne pas s'interroger sur l'ouverture du code, c'est raisonner à court terme... ce que tu sembles pourtant "nous" reprocher. Du code ouvert et libre, ça signifie que quoi qu'il arrive, on pourra toujours apporter des modifications aux produits qu'on a acheté, c'est un aspect qui devrait être au coeur des préoccupations des entreprises.
Du code fermé, par contre, c'est se rendre dépendant d'une entreprise. Si elle survit tant mieux, sinon il faut acheter un nouveau produit.
Voilà une raison OP (Orientée Pognon) de préférer des produits libres à des produits propriétaires. Histoire de (tenter de) te convaincre que les gens qui s'intéressent à l'aspect libre ne sont pas tous des crétins profonds.
«Je trouve légitime que des programmeurs veuillent se faire rétribuer pour leur travail...soit en demandant de l'argent, soit en veillant à ce que son nom soit attaché au code...ce que la GPL ne permet pas»
L'as-tu lue, la GPL ? Ok, tu n'es pas d'accord sur le fait que l'on peut être payé et développer du GPL, c'est ton droit de nier les exemples existant. Mais sur le deuxième point, c'est n'importe quoi. Tu confonds allègrement logiciel libre et domaine public. La GPL conserve évidemment le copyright des auteurs sur leur code.
Tu n'as pas l'impression que le nom des développeurs est associé à leur code ? Bien, je suis sûr que tu peux citer de mémoire, comme beaucoup de gens ici, le nom de quelques développeurs du noyau Linux. Peux-tu faire de même pour les développeurs de Windows ?
Autres gens connus, le développeur d'Emacs, celui de Python, celui de Perl. Connais-tu des développeurs de Visual Basic, d'ASP, de Visual Studio ? (exemples pris au hasard, de logiciels propriétaires en général)
[^] # Re: Microsoft et langue de bois...
Posté par Yusei (Mastodon) . En réponse au journal Microsoft et langue de bois.... Évalué à 1.
Vu le smiley je suppose qu'il s'en est rendu compte, mais ça montre bien qu'il esquive les questions alors qu'il pourrait y répondre.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Yusei (Mastodon) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 2.
Il s'agissait d'un type qui voulait que "les gens" l'aident à faire ses gros calculs, en faisant tourner une appli en tâche de fond pendant un mois. Une sorte de Seti@Home en moins distribué.
Sachant que pour avoir un maximum de contributeurs il faut un truc portable et simple à installer, et sachant qu'il ne doit pas être un informaticien professionnel, Java est une solution adaptée. D'autant plus que sa lenteur ne sera pas pénalisante, car sur un calcul d'un mois, les parties lourdes seront compilées par le JIT.
Donc pour moi, c'était un choix correct. Je précise d'ailleurs qu'il s'agit de la plateforme Java, pas le langage, car il peut très bien avoir codé le tout en ADA, et compilé pour une JVM, par exemple.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Yusei (Mastodon) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 2.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Yusei (Mastodon) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
Moi oui, et sincèrement, SWING c'est de la daube. Ça rame sur un portable que j'ai acheté en septembre 2003, c'est inadmissible et ça donne une mauvaise image de Java qui n'est pas si lent que ça en réalité. C'est ce qui fait que sur slashdot hier des gens critiquaient l'utilisation de Java pour faire des calculs scientifiques distribués, alors qu'en fait c'était un choix parfaitement adapté.
Certes, c'est moins lent qu'avant, mais quand je vois un programme tout simple qui rame sur une machine que je trouve trop puissante pour ce que j'en fais, non merci.
(Si je dis ça, ce n'est pas pour troller sur Java, j'aurais de bien meilleures pistes de trolls à ce sujet hein :-)
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Yusei (Mastodon) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 2.
S'il y a d'autres solutions ça m'intéresse, car je ne vois absolument pas comment on peut, sans compiler et sans interpréter, exécuter du code que l'on ne connait pas au moment de la production du logiciel :-)
Après, pour ce qui est de faire des inclusions conditionnelles de code à coups de bibliothèques dynamiques ok, mais c'est moins puissant que ce que je décrivais.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Yusei (Mastodon) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
C'est juste des exemples de ce qu'on trouve parmi les langages dits de "haut niveau", que je trouvais assez représentatifs concernant la différence interpretation/compilation.
Pour l'indépendance par rapport au matériel, par exemple, l'interprétation est aussi une bonne solution. D'ailleurs si Java est indépendant de la machine c'est en partie parce qu'il est interprété (au niveau du bytecode), ce qui simplifie bien la vie.
(Je précise avant qu'on me tombe dessus que l'indépendance par rapport au matériel peut aussi se faire via une bibliothèque bien foutue, mais dans ce cas là ça n'est plus un caractère inhérent au langage.)
«[...] on dit souvent que c'est une fonctionnalité nécessaire. Ce qui m'étonne dans ce discours, c'est que la réflexivité n'est qu'une technique, qu'un moyen. [...] »
Oula, tu t'embarques bien loin à répondre à des objections que personne n'a formulé ici :-)
Pour moi la réflexivité et le changement du code à l'exécution c'est un truc pratique, et ça fait partie de ce que j'aime avoir à disposition, c'est tout. Or c'est infiniment plus facile à faire en interprété qu'en compilé.
# Re: Microsoft et langue de bois...
Posté par Yusei (Mastodon) . En réponse au journal Microsoft et langue de bois.... Évalué à 1.
Quel standard propriétaire ? Pouvez-vous me donner le nom d'un standard ouvert significatif qui ne serait pas supporté par la plate-forme Microsoft ?
Boo : Compte tenu de ce que vous dites de la force de Windows, pensez-vous que Windows est menacé par Linux ?
La question est un peu trop vaste :-) ! Linux est une réalité sur les serveurs, mais prend surtout des parts de marché à Unix. La concurrence est saine et nous permet de nous améliorer !
_megamoule : Pouvez-vous me donner le nom d'un standard ouvert significatif qui ne serait pas supporté par la plate-forme Microsoft ?
Oui, le PNG, SVG et autres :-).»
Il est très très fort ce type :-)
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Yusei (Mastodon) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
En C/C++, pour ce dernier point, je suppose qu'il faut recompiler à la volée, et c'est pas terrible.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Yusei (Mastodon) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 2.
C'est pas spécialement vrai, mon portable ne possède que 256 Mo de RAM, et je pourrais utiliser des logiciels faits en Java.
Ceci dit je trouve ça assez inquiétant que pour toi le libre doive remonter la barre des exigeances techniques à 512 Mo. Il y a des tonnes d'applications où ce n'est pas envisageable, et tout le monde ne peut pas se procurer une machine dernier cri. À moins d'exclure les pays du Sud, on va se trainer des PII pendant au moins dix ans encore.
«il y a même des gens pour dire que des langages interprétés sont bien car ils sont encore plus haut niveau que Java»
Oui, clairement. Si tu as eu une telle révélation avec Java, essaye le Ruby ou le Python, tu verras que c'est beaucoup plus agréable que du Java, et que la plupart du temps la rapidité est au rendez-vous.
En plus c'est libre, ouahou.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Yusei (Mastodon) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 4.
L'argument est boîteux, de prétendre que la liberté c'est de savoir incorporer les trucs non-libres. Un truc non-libre, c'est pas libre, même si c'est gratuit et vachement bien (au passage, on pourrait débattre de la qualité de Java par rapport à certaines solutions libre, hein :-).
[^] # Re: quel intéret pour le libre ?
Posté par Yusei (Mastodon) . En réponse à la dépêche Docker 0.14, un gestionnaire de paquets pour Windows. Évalué à 1.
Mais bon de toutes façons Windows c'est pas libre, alors c'est un peu chipotter. Et histoire de finir sur un lancement de débat: vous pensez que c'est bien pour le libre de corriger un des plus gros problèmes de Windows, à savoir la gestion de paquets ? :-)
[^] # Re: idée en l'air contre le spam
Posté par Yusei (Mastodon) . En réponse au journal idée en l'air contre le spam. Évalué à 1.
Mais... bogofilter ça marche bien, vous ne trouvez pas ? Ça en laisse passer un peu, mais c'est moins lourd pour les gens qui t'écrivent et ça ne valide pas l'adresse.
# Re: Écran de portable qui ne tient plus debout!
Posté par Yusei (Mastodon) . En réponse au journal Écran de portable qui ne tient plus debout!. Évalué à 2.
Moi j'ai cassé le p'tit bout de plastique qui met l'ecran en veille quand je le referme, mais ça doit être plus facile à résoudre comme problème.
[^] # Re: éternel dilemne
Posté par Yusei (Mastodon) . En réponse au journal éternel dilemne. Évalué à 3.
Là excuse moi mais c'est du foutage de gueule, un peu =)
Tu vantes les systèmes sans gestion de dépendances, et quand on te montre comment faire ça avec des RPMS, tu dis que le système risque de ne pas être cohérent...
La DB est nécessaire uniquement pour garder la liste des paquets installés, dans ce cas. De mémoire, il me semble que Slack se souvient aussi de la base des paquets installés.
«Comme X quand tu installes Emacs (ah non, c'est Debian, ca) ?»
Non:
http://packages.debian.org/unstable/editors/emacs21-nox(...)
[^] # Re: éternel dilemne
Posté par Yusei (Mastodon) . En réponse au journal éternel dilemne. Évalué à 3.
Je suppose que tu voulais dire "peut ne pas etre parfaite", et je répondrais en ce sens: une dépendance peut ne pas être parfaite comme un logiciel peut ne pas être parfait. Je ne me refuse pas le droit d'utiliser des logiciels faits par d'autres sous prétexte qu'ils peuvent ne pas être parfaits. Idem pour les paquets avec gestion des dépendances.
D'autant plus qu'une dépendance foireuse est presque sans conséquences. Au pire ça installe des choses en trop, sinon tu dois installer la dépendance toi même (comme avec un système sans gestion des dépendances donc).
Si on était constamment confrontés à des paquets foireux qui refusent de s'installer à tort, je ne dis pas, mais j'ai dû rencontrer un paquet foireux en deux ans d'utilisation de Debian unstable. Comparé au temps que j'ai gagné à ne pas aller télécharger tous les paquets à la main...
[^] # Re: éternel dilemne
Posté par Yusei (Mastodon) . En réponse au journal éternel dilemne. Évalué à 3.
Ah mince, moi à la lecture il m'avait semblé voir une question plutôt qu'une affirmation. Étonnant que tu confondes, tu sembles bien calé niveau affirmations.
«qui montre une meconnaissance assez eleve du systeme»
Amusant de voir à quel point le bas niveau de tes interlocuteurs te permet d'éviter de répondre :-)
«Chose que bien entendu, on fait tout les jours en temps limite»
Sous prétexte que les tâches d'administration ne se font pas tous les jours, on devrait les rendre plus fastidieuses ? Je ne pense pas.
Effectivement ce que dit le monsieur au dessus est pertinent. Tu me disais ailleurs que je devais pouvoir mémoriser moi même les dépendances entre logiciels (ne pas effacer telle lib si elle est requise ailleurs), car il faut "savoir ce qu'on fait". Mais si tu administres un paquet de machines différentes, tu dois aussi tout mémoriser pour chacune d'entre elles ? Savoir que la libtruc est requise sur la machine 42, mais pas sur la machine 36 ?
[^] # Re: éternel dilemne
Posté par Yusei (Mastodon) . En réponse au journal éternel dilemne. Évalué à 2.
C'est profondément ridicule. Je sais très bien à quoi sert libxml1, en quoi est-ce que ça me permet de savoir si j'ai des logiciels qui l'utilisent ?
J'ai environ 1500 paquets installés sur ma machine perso, je suis censé me souvenir des dépe^Wbibliothèques utilisées par chacun d'entre eux ? Non merci :-)
«C'est vrai que si tu as une distrib avec 2000 paquets d'installe, tu ne dois pas etre habituer a voir les choses simplement.»
Si pour toi, voir les choses simplement, c'est savoir ce que chaque programme utilise comme bibliothèques, je ne vois certainement pas les choses simplement :-)
«S'il-te-plait, arrete d'ecrire que je trouve les dependances inutiles.»
Moi c'est l'impression que me laisse ton post même après re(re)lecture.
«Tu m'accuses de parti pris, apparemment.»
Non je t'accuse de raconter n'importe quoi, c'est pas pareil. Tu peux très bien être convaincu du bien fondé de tes arguments :-)
«Ah bah si on peut alors, le monde est sauve. Montre moi un exemple pour voir ce que ca donne en pratique.»
Et voilà, la dérision pour contourner l'argument, merci pour cet exemple de rigueur.
Remise dans le contexte: tu reproches que certaines dépendances ne sont pas requises, car le logiciel fonctionne sans. Je te dis qu'effectivement, on peut définir des dépendances non-requises, sans lesquelles le logiciel s'installe et fonctionne. En effet, "le monde est sauvé", ton problème n'en est pas un. Qu'est-ce que tu ne comprends pas là dedans ?
Je te donne un exemple que j'ai rencontré hier, puisque c'est trop abstrait: si tu installes libsoap-ruby, tu obtiens de quoi faire du SOAP en ruby. Cette bibliothèque n'exige pas que tu possèdes webrick (une bibli pour faire un serveur web en ruby), mais si tu la possèdes, alors tu as accès à plus de fonctions de libsoap-ruby.
C'est bien ce dont tu parlais non ?
«Je confirme que fractionner les paquets, a cause des dependances, pose plus de probleme qu'autre chose.»
Je confirme le contraire, et on est bien avancés...
«C'est plus simple ?»
Oui, sauf si tu t'amuses à faire la gestion des dépendances à la main. N'importe quel système bien foutu les gère à ta place, et donc installe ce dont le paquet a besoin. Pas de "ça marche pas, il faut libtruc-machin" si les paquets sont bien faits (et ils doivent l'être vu que je n'ai pas encore eu de problèmes depuis que j'utilise ma debian).
«Hors-sujet»
Certainement pas, analogie. Ton système de fichier est une base de données, s'il casse tu es mal. Un système de gestion de paquets utilise une base de données, s'il casse tu es mal (mais beaucoup moins).
En suivant ton raisonnement, il est dangereux d'utiliser un système de fichier. C'est absurde donc ton raisonnement est faux.
Si c'est moi qui me trompe, merci de m'expliquer pourquoi avec autre chose qu'un Hors-sujet.
«Tu es serieux ? Parce que la ta credibilite vient d'en prendre un coup.»
Tout à fait. Si les bases RPM plantent c'est dommage (jamais vu, mais je fais confiance à google), par contre ta généralisation est abusive. Partir d'un exemple d'un truc foireux pour démontrer que tout est foireux, c'est comme dire que l'informatique ça plante parce que Windows ça plante.
Il y a des tas d'application qui utilisent des bases de données et qui ont besoin de fiabilité, alors si tu peux démontrer que les BdD c'est pas fiable, tu vas révolutionner l'industrie de l'informatique, je tiens à te prévenir :-)
Le truc que tu as coupé dans ce que je dis, c'est aussi qu'un plantage de la BdD de gestion des paquets, ça ne casse pas le système. Ça peut être assez lourd à reconstruire, mais le système continue de tourner sans s'en préoccuper. C'est juste genant quand tu veux installer un nouveau paquet. Alors qu'un plantage de la base de registres de Windows, c'est le système qui ne boot plus.
«Peut-on installer une distrib RPM sans la DB ?»
Je ne vois pas l'intérêt, mais oui, un RPM ce n'est qu'un paquet semblable à ceux de Slack avec en plus des infos de dépendances. Déjà, si tu n'aimes pas les dépendances, tu peux forcer l'installation sans vérification. Ensuite, si tu n'aimes pas la BdD tu peux utiliser le RPM comme un .tar.gz, mais ça ne sert à rien. Autant prendre les .tar.gz.
[^] # Re: éternel dilemne
Posté par Yusei (Mastodon) . En réponse au journal éternel dilemne. Évalué à 3.
Tu peux savoir ce que c'est sans savoir si un logiciel installé en a besoin. Par exemple j'ai libxml1 et libxml2, je sais très bien ce que c'est, mais comment savoir si j'ai des logiciels qui utilisent libxml1 ?
Je pourrais, effectivement, compter sur ma mémoire, mais je préfère laisser l'ordinateur faire ça, perso...
«ce ne sont pas les dependances qui font forcement la necessite d'un logiciel»
Les dépendances ne résolvent pas tous les problèmes, donc elles ne servent à rien ?
«D'autre part, les gestions sont souvent mal ficelees avec les rpms ou deb.»
C'est idiot comme argument. Pour montrer que les dépendances sont inutiles, tu expliques qu'elles sont mal faites. Donc si elles étaient bien faites, elles seraient utiles ?
«Ce n'est pas parce qu'un logiciel A a une dependance avec B qu'il ne va plus marcher du tout si je retire B. Dans la plupart des cas, le logiciel marche, simplement avec une fonctionnalite en moins»
Sais-tu que l'on peut faire une distinction entre dépendances requises et optionelles ? Dans un paquet bien fait, si tu retires une dépendance requise, c'est cassé.
«Et si on a pas besoin des include ou des libs, et bien tant pis, tous le monde ne bosse pas sur de l'embarque ou des serveurs i486, il y a de la place sur les disques quand meme.»
"Moi j'installe tout, donc pas de problèmes de dépendances", ah ben oui, vu comme ça :-)
«Enfin, une base de donnee qui plante pose souvent de serieux problemes et met en jeux la sanite de tout le systeme. Je suis desole de choquer mais cela me semble tres similaire a la base de registre de Windows. Ca ne me semble pas solide comme methode.»
Mouahaha :-)
Les bases de données, c'est d'la merde, si ça plante c'est planté. Et ton système de fichier aussi, s'il plante tu es mal, vu que c'est une sorte de base de données. Le truc c'est que ça n'a quasiment aucune raison de planter, et que dans tous les cas la base de paquets peut être reconstruite.
Le défaut de la base de registres c'est que c'est un format obscur qui plante tout le temps et qui n'est jamais nettoyé. Rien à voir avec une vraie base de données bien gérée.
Là c'est plus les systemes de gestion de paquets que tu jettes à la poubelle, c'est tout ce qui utilise une BdD...
«Le systeme de la slack est honnetement le plus fiable a l'utilisation»
Pourquoi ?
(Je veux bien te croire, j'ai été utilisateur de Slackware, mais au moins explique pourquoi. Je considère que ton "incassable" n'est pas un argument vu que la base de paquets de slack c'est aussi une base de données :-)
[^] # Re: idée en l'air contre le spam
Posté par Yusei (Mastodon) . En réponse au journal idée en l'air contre le spam. Évalué à 2.
[^] # Re: éternel dilemne
Posté par Yusei (Mastodon) . En réponse au journal éternel dilemne. Évalué à 1.
[^] # Re: Easter Egg de Microsoft Word
Posté par Yusei (Mastodon) . En réponse au journal Easter Egg de Microsoft Word. Évalué à 1.