C'est rarement utile, mais ça arrive que la sémantique des arguments change avec leur nombre et ordre. Par exemple la classique fonction range() ne prend pas d'arguments par mot-clé ; ça va pouvoir être formalisé plus proprement dans sa signature avec Python 3.8.
C'est pratique aussi pour les IDE qui extraient un fichier .py représentant l'interface d'un module écrit en C dans lequel les fonctions utilisent uniquement l'ordre des arguments.
Avec reportlab c'est la sanction immédiate, en Go l'erreur est pardonnée.
En l'occurrence c'est plus un biais de confirmation ici.
Bien sûr que Go est plus performant (code natif, typage statique, parallélisme…), mais dans ce cas :
soit c'est une limite de conception (le PDF est entièrement en RAM) et le code en Go explosera lui aussi, mais plus tard (au sens 'PDF avec plus de pages') ; "l'erreur est pardonnée" n'est vrai que parce que la limite, plus lointaine, te suffit (tant mieux).
soit c'est une différence de conception (ex: en Python le PDF est entièrement en RAM, en Go il est écrit au fur et à mesure dans un fichier/socket), et dans ce cas comparer les langages est injuste (rien n'empêche—dans l'absolu—de faire la même chose en Python).
D'un autre côté il faut quand même vérifier, à un moment donné, que la contrainte arbitraire 160×205px est respectée ; si on met une PNG de la taille qu'on veut on a une cartouche avec la capacité qu'on veut.
Après j'imagine qu'il y a sûrement une bonne raison (au moins à la base) pour avoir opté pour cette technique (genre ne faire qu'une seule vérification et pas deux).
À moins que je n'ai pas compris ce que tu appelles "embarquer", tu es es passé à côté de pleins de logiciels (typiquement écrits en C/C++) et qui embarquent Python. On pensera par exemple à Gimp et à Blender.
aux dépens de la robustesse du langage (ce qui est indéfendable).
Ça n'est pas indéfendable de manière absolue, c'est un compromis tout à fait subjectif (que tu peux tout à fait refuser hein). Par exemple si ça provoque 0.001% (chiffre sorti de mon chapeau pour l'exemple) de bug mineurs en plus mais que ça permet d'améliorer sensiblement la beauté de l'ensemble du code (ne pas avoir à "beautifier" le code d'une bibliothèque externe que tu lis, tu te sens de base à peu près chez toi), on peut tout à fait comprendre que certains acceptent le compromis sans souci.
Après je suis aussi le premier à dire que pour du code hyper critique il vaut mieux éviter le Python (et le C)…
Tu affirmes que l'indentation en Python est une cause monumentale de bugs, mais tu ne nous dis toujours pas comment tu le sais. Si je comprends bien tu ne codes globalement qu'en C toute la journée donc ce n'est pas ton expérience personnelle ; et toujours aucun lien vers des gens qui font du Python et qui parlent de ce (soit-disant) gros problème (alors que des blogs qui se plaignent de l'absence de typage statique ou du GIL ce n'est pas ce qui manque)…
Chose amusante, Jython (implémentation de Python en environnement Java) permet le vrai parallélisme (même si évidemment il y a un "stop the world" lors du travail du GC) ; après comme ce n'est pas compatible avec les modules écrits en C pour l'implémentation la plus utilisée (CPython), je ne pense pas que grand monde s'en serve.
ayant mené à des tétra-chiées de bugs sans doute fort coûteux.
Sans doute… ou pas. S'il y en a des "tétra-chiées" tu ne devrais pas avoir de problème à nous en indiquer quelques uns.
Après cela, on a beau jeu de dire que le C est dangereux…
Parce que des vulnérabilités dans du code C ayant mené à des soucis énormes de sécurité (entre autres) ce n'est pas difficile, il y en a beaucoup. Par exemple les différentes failles dans OpenSSL de ces dernières années (Heartbleed et compagnie) ; évidemment C est très utilisé (et pas au mêmes endroits que Python, donc difficile de comparer), et aucun langage n'empêchera jamais de coder salement etc… donc je ne vais pas tout mettre sur le dos du C. Mais l'existence de "tétra-chiées de bugs fort coûteux" est sans appel.
Reste que dire que C est plus fiable que Python pour une raison de re-formatage du code source c'est assez ridicule. J'écris du python depuis 2004 (et à temps plein de puis 2009) et j'ai du être piégé une poignée de fois par un problème d'indentation foireuse, et j'ai au pire perdu quelques minutes à trouver pourquoi mon code ne marchait pas ; ça n'a jamais donné lieu à un bug qui explose chez un utilisateur. Peut-être parce que je teste mon code, j'évite de le committer directement avoir l'avoir écrit (un buffer-overflow il faut passer à un niveau supérieur niveau test, genre fuzzing, pour les trouver efficacement, c'est très loin d'être trivial). Il y a des tas de vrais problèmes dans python, mais "ohalala j'ai copié-collé 3000 lignes de codes trouvées sur le Web, j'ai pas testé et ça me faire du caca" n'en est pas un.
Hum j'ai souvenir d'une série d'articles dans LinuxMag (il y a plusieurs années) sur l'écriture d'un noyau en Ada (et notamment un passage corsé sur la gestion de la mémoire virtuelle). Tu me mets le doute du coup sur comment ça se passe avec le runtime de Ada ; il y a peut être moyen de le désactiver (comme pour la gestion des exceptions en C++).
Si tu veux étudier le langage assembleur pour un programme C dont tu as les sources, tu peux utiliser la sortie assembleur de ton compilateur plutôt que de désassembler un binaire (option -S de gcc il me semble).
je constate que la taille des instructions (dans la fonction start) vaut parfois 2 octets, puis 3, puis 1, puis plus loin 7… comment le processeur peut savoir que l'instruction vaut parfois des tailles différentes, sachant que la taille de mon bus est de 64 bits soit 8 octets, donc on pourrait penser que toutes les intructions vallent 8 octets ?
Ça dépend de ton processeur ; sur MIPS 32 bits, toutes les instructions font 32bits par exemple (du coup pour stocker certaines constantes dans le code il faut parfois 2 instructions). Sur x86, la taille des instructions varie ; ça rend leur décodage plus complexe, mais en pratique le code binaire est souvent plus compact. De plus, il ne faut pas oublier que les x86 ont toujours gardé la compatibilité binaire ascendante, et donc ton x86 64bits comprend les instructions 8086/286/386/… et on comprend bien que les instructions du 386 ne sont pas en 64bits. L'ensemble des instructions d'un processeur est appelé ISA, et tu dois pouvoir trouver cette spec' pour le processeur qui t'intéresse.
Comment le processeur s'y retrouve-t'il ? Comme d'habitude, il lit l'OpCode en début d'instruction, il sait alors ce qu'est l'instruction, et donc sa taille. Les instructions sont chargées dans le processeur depuis le cache mémoire (qui est bien rempli depuis la RAM avec plusieurs instructions et en utilisant efficacement ton bus de 64bits).
Si tu regarde attentivement, la réponse 2 a habilement tronqué cette partie : Mais c'est un détail.
Je n'ai pas tronqué "habilement" cette partie afin d'en changer le sens ; cette partie ne change absolument pas le sous-entendu de ta phrase.
Exemple:
"Par ailleurs, XXX n'est pas performant, c'est écrit en Python. Mais c'est un détail."
Bon et ben ça sous-entend clairement que le logiciel XXX est lent, et que c'est la faute (au moins en partie) de Python. Le "Mais c'est un détail" s'applique à l'ensemble le la première phrase, et n'enlève pas le sous-entendu de la première phrase.
En gros tes 2 phrases se comprennent (pour plein de gens) telle que:
"Par ailleurs, PGP n'est pas libre car c'est commercial. Mais c'est un détail."
(et donc commercial implique non-libre/propriétaire, ce qui est faux)
Et pas:
"Par ailleurs, PGP n'est pas libre, et en plus, et ceci n'a rien à voir avec le début de la phrase, c'est commercial. Mais c'est un détail."
Vous devriez mettre à jour les captures qui sont ici […]
Vous avez raison ; l'interface a pas mal évolué (notamment avec la 1.7 sortie l'année dernière) et mon collègue qui s'occupe du site est assez débordé.
[…] je suis toujours content quand je vois arriver une de vos dépêches : c'est sympa les logiciels qui mûrissent sur le long terme.
Merci beaucoup ! C'est évidemment une fierté pour nous d'arriver à développer un logiciel libre avec nos petits moyens ; ça fait plaisir de voir que des gens aiment mes dépêches (je sais qu'il est plus facile de prendre la plume quand on est mécontent).
C'est le genre de chose qu'on peut faire avec des fichiers plats mais le processus est lourd et encore plus à l'heure où les ERP se sont ouvert à l'extérieur via des webservices ou autres techno.
Le cas qu'on a pu avoir c'est par exemple un client avec un vieil ERP développé en interne et tournant sous AS400 ; l'équipe en interne impose que la communication se fasse avec un fichier plat généré toutes les nuit par l'ERP. Si on a le choix de la technique on partira évidemment plus sur des web-services.
J'aimerai beaucoup avoir l'occasion de travailler sur la communication avec d'autres logiciels libres ; en pratique ce n'est malheureusement une demande de nos clients actuels (ce qui touche à la problématique du financement des logiciels libres).
Il n'y a pas (encore) d'API au sens Rest si c'est votre question. Il y a bien longtemps un de nos clients en voulait une rapidement, et j'avais donc fait une v0.1 ; mais finalement ledit client à changé d'avis et nous n'avons jamais eu l'occasion de tester en production et donc d'intégrer ce code.
Ils arrivent régulièrement à mes collègues qui s'occupent des intégrations client de devoir s'intégrer avec des outils maison (comme on peut s'en douter) ; et pourtant on n'a pas encore eu une vraie occasion de coder une API Rest générique. En effet parfois ces outils maison pondent des fichiers plats (qu'on va par exemple lire la nuit) ; parfois ce sont ces outils qui ont une API sur laquelle on doit s'interfacer ; et parfois mes collègues rajoutent une mini API (avec Django Rest Framework) pour les besoins spécifiques.
Donc ça arrivera soit le jour où on estimera que ça nous ferait globalement gagner du temps d'en mettre une générique (plutôt que d'en faire des had-oc), soit le jour ou un utilisateur sera prêt à investir pour (en temps/code ou en argent)—sachant que ce n'est sûrement pas énorme (mais bon comme toujours, pour faire bien, il faut un minimum de temps).
En espérant avoir répondu correctement à votre question.
Si tu es suffisamment habile dans ce "test d'intrusion", il y a fort à parier qu'à la vue du résultat l'auteur voudra ajouter des éléments supplémentaires à sa licence propriétaire pour se sentir protégé du pire.
Du coup tu dis exactement la même chose que moi, à savoir qu'"éviter d'utiliser la popularité d'un héros pour passer un message contraire" serait un prétexte pour la plupart des artistes qui auraient tenu de tels propos. Le fait qu'ils veuillent tout protéger n'ayant jamais été un problème dans mes précédents messages ; je n'ai jamais fait que pointer une certaine hypocrisie. Mais pas la peine de s'offusquer pour autant, nous sommes tous des "hypocrites", dans le sens où nous sommes plein de contradictions (pas dans le sens où nous serions malintentionnés) ; mais interroger nos contradictions est intéressant, c'est ce qui nous fait évoluer.
Tu parles de tester la bonne foi des gens avec zéro empathie sur leur peur […] t'as pas l'air de vouloir comprendre en quoi ta question est ultra délicate et personnelle.
Je crois que c'est là le souci ; je n'ai rien demandé à personne de réel, juste posé une problématique. Il n'a jamais été question d'interroger avec une lampe braquée dans la figure (là encore mon propos était tout à fait neutre, pourquoi imaginer la pire version ?) ; tu n'as aucune idée de la façon dont je me serais adressé à un artiste réel, et tu me fais un procès d'intention.
Tu dis être dans le milieu artistique, tu t'es peut-être senti agressé par mes propos ; si c'est le cas j'en suis désolé. Mais relis mes propos, je n'ai jamais demandé à qui que ce soit de libérer quoi que ce soit, encore moins sans expliquer les conséquences d'un telle libération. Je me contente de faire et financer du code et de l'art libres en posant donc cette question "ultra délicate et personnelle" à moi-même avant tout. Mais si
"la question de la licence ne se pose pas […]", je trouve dommage que ta position sur le sujet ait l'air d'être en substance .
Ça indique que tu supposes que l'artiste se prend pour le seul être qui puisse modifier son œuvre. Ou alors j'ai pas vraiment compris ce que tu voulais dire.
En effet on ne s'est pas compris ; mon propos est beaucoup plus neutre. Je parle de quelqu'un qui n'imagine juste pas d'utilité autre que la sienne (un peu comme un script shell personnel qu'on ne diffuse pas car trop spécifique). C'est plus clair ?
Un style graphique n'est pas verrouillable, je suis même pas sûr que ce soit possible aux USA.
Je ne parierai pas là dessus, avec Samsung condamné pour avoir copié les bords ronds par exemple ; ce n'est pas tout à fait un style graphique, et donc je n'affirme pas catégoriquement que c'est possible, mais que c'est la tendance actuelle.
Et je parle bien de redessiner des décors et de s'en inspirer, pas de les décalquer. C'est la même chose quand tu dessines d'après des photos ou des croquis non libres. Les artistes sont loin d'être tous des rentiers, ils savent faire la différence entre un pompage paresseux et un travail de réappropriation personnelle.
En gros tu me dis qu'on a vraiment trop de chances d'avoir quand même le droit de s'inspirer d’œuvres propriétaires ?
Non je t'explique que ton test ne fonctionne pas puisqu'il dépend de la sensibilité de l'auteur envers ce qui représente son œuvre par autre chose que ses personnages. […]
Comme je l'ai dit, mon test est destiné à un artiste qui dit "je libérerai bien, mais mon héros je veux contrôler ses propos" et tu l'appliques à un artiste qui dit directement/franchement qu'il ne veut rien libérer, pas étonnant qu'"il ne fonctionne pas"…
Pas la peine de rappeler à chacun de tes messages que oui la majorité des artistes veulent contrôler leur œuvre, je pense que tout le monde ici est au courant. Le commentaire auquel j'ai répondu à la base parlait de protéger un minimum de chose par une marque, tout en libérant le reste et je réfléchissais sur ce thème de mélange libre/marque, et tu t'acharnes à rappeler que des tas de gens ne veulent rien libérer du tout. C'est vrai, et personne n'a dit le contraire, mais aucun rapport avec mes messages.
Désolé si c'est l'impression que ça donne, mais ce n'était pas mon intention et je ne vois pas du tout de laquelle de mes phrases tu parles. Peux-tu préciser où ?
Rien n'empèche toutefois de redessiner un décor à sa sauce ou de s'inspirer du style d'un auteur.
C'est vite dit ; avec la tendance actuelle de tout verrouiller au nom de la sacro-sainte propriété intellectuelle (concept au final très récent à l'échelle de l'histoire—on créait déjà des tas choses formidables avant ça) notre système a au contraire des tas de façons de nous empêcher de faire des choses. Ce qui est stupide vu que la création pure n'existe pas, et les œuvres sont toujours ce qu'elles sont uniquement grâce aux œuvres précédentes (que l'inspiration soit consciente ou non, assumée ou non).
alors c'est qu'il considère que son décor est autant une partie intégrante de son travail que ses personnages.
Tu sors ma phrase de son contexte. Je parle des auteurs qui se réfugient derrière "mon personnage iconique reconnaissable par les enfants ne doit pas dire des horreurs" (et je propose de tester dans quelle mesure c'est un prétexte ou pas selon les cas), et tu m'expliques qu'il existe des auteurs qui vont dire explicitement "je ne libère rien c'est un tout" ; je le sais très bien mais en quoi ça nous avance ?
Certes, mais là se pose la question de la rémunération du travail […]
Il se trouve que j'ai posé la question de l'impact économique dans le premier commentaire de ce journal, donc oui je pense que la question est intéressante. Et la réponse de Boulet est "pas d'impact économique significatif".
Du coup l'aspect économique n'étant pas bloquant (selon lui), je m'intéresse à un autre aspect dans ce thread.
La plupart des artistes n'ont pas le melon suffisamment gros pour penser de manière aussi condescendante.
La plupart des artistes ne se sont sûrement pas posé la question du libre car le libre reste une philosophie/approche récente en ce qui concerne l'art. Mais ici on s'intéresse à ceux qui se sont posé la question.
Il y a aussi une distinction entre adapter à sa sauce des morceaux d'une œuvre (inspiration, hommage) et reprendre des bouts de travaux complets (plagiat).
Si un artiste A libère une œuvre #1 (c'est un acte volontaire) et qu'un artiste B réutilise ladite œuvre dans le respect de la licence libre pour créer une nouvelle œuvre, cette dernière est une œuvre collaborative avec pour auteurs A & B, et il n'est nullement question que ça soit caché. Ce n'est en aucun cas un plagiat, on modifie une œuvre pour en créer une nouvelle avec l'accord du créateur originel ; c'est le principe du libre.
Maintenant une licence libre peut être violée tout comme une licence propriétaire, cela n'est pas un problème spécifique au libre.
Le chara-design n'est qu'une partie de l'œuvre, pas plus importante que le reste.
Tout dépend de ce qu'on entend par "important".
Dans un précédant débat sur l'art libre (désolé j'aurai peut-être du plus expliciter), un argument contre le libre et qui ressemble à ce qui est dit plus haut sur la protection des marques était du genre:
"J'ai créé un super-héros, CastorMan, qui a des milliers de fans et qui véhicule des valeurs positives de tolérance et d'entre-aide ; je ne veux pas que des gens puissent profiter de la notoriété de mon personnage pour diffuser des messages haineux."
Du coup, de la même manière que Firefox protège sa marque (on ne peut pas prétendre être le FireFox officiel et surfer sur sa notoriété) mais ouvre au final tout le reste, je me demande dans quel mesure un artiste serait prêt à libérer tout ce qu'il y autour de ses personnages iconiques.
Évidemment que ça poserait des soucis en pratique de gérer des licence différentes pour les personnages principaux et pour le reste ; mais je trouvais que c'était une question "philosophique" intéressante à poser à un artiste qui serait dans cette optique. Par exemple s'il refuse théoriquement de libérer une case avec un décor "passe-partout" (sans les héros dont la libération poserait problème selon lui), alors c'est que cette histoire de protection de marque/héros est un prétexte.
Tu as tout à fait raison, c'est potentiellement difficile de réutiliser des bouts d'une œuvre pour en faire une autre…
…mais ça ne change rien à mon propos. Dans le cas qui nous intéresse, l'approche libre c'est de dire "Voila mon travail, vous pouvez en faire ce que vous voulez [*], ça vous sera peut-être utile" ; et dire "je ne libère pas parce que de toute les façons ne vois pas comment vous pourriez vous en resservir" est juste un prétexte. Si c'est difficilement réutilisable tant pis ; toute la beauté de la chose est que si quelqu'un trouve une façon de s'en resservir, il le pourra. Par exemple, une case de BD avec un joli décor pourrait servir de (base à une) jaquette d'album de musique.
[*] dans les limites imposées par la licence évidemment.
Le libre n'est pas tout à fait à l'opposé de ça, non. Linux, Firefox, Libreoffice, Nextcloud, Dolibarr par exemple sont des marques déposées. C'est la même démarche que de protéger ses personnages.
Si demain les créateurs de Firefox ferment le code source en disant que le libre c'est intéressant mais qu'il faut bien qu'ils protègent leur marque, on ne pourra pas dire qu'ils sont favorables au libre et ne font que protéger leur image.
Boulet serait-il prêt à libérer ses scénarios et le graphisme des décors, et garder le graphisme de ses héros sous licence propriétaire, afin qu'on ne puisse pas se servir de son image pour porter un autre message tout en libérant un maximum de chose ? Seul lui a la réponse évidemment (je ne vais pas faire de procès d'intention), qui permettrait de savoir à quel point il est sincère.
Pour lui ça ne peut pas avoir d'impact significatif (à terme visible) sur la situation (catastrophique) des auteurs.
En même temps l'art libre, de même que le logiciel libre, n'a jamais eu la prétention d'améliorer la situation (financière on imagine bien) de leurs créateurs ; le libre concerne avant tout celui qui reçoit. Le vaccin contre le cancer ne va pas non plus améliorer la situation financière des auteurs de BD, ce n'est pas anecdotique pour autant…
La question est plutôt de savoir si, dans la mesure où le business model est différent, cela peut avoir un impact négatif sur leur situation ; et vu ce qu'il avait dit auparavant ça ne serait pas étonnant qu'il le pense. Car si ce n'est pas le cas ça veut dire qu'un auteur peut sans problème donner plus/mieux à son public.
[^] # Re: Python se rapproche du Perl ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 5.
C'est rarement utile, mais ça arrive que la sémantique des arguments change avec leur nombre et ordre. Par exemple la classique fonction
range()ne prend pas d'arguments par mot-clé ; ça va pouvoir être formalisé plus proprement dans sa signature avec Python 3.8.C'est pratique aussi pour les IDE qui extraient un fichier .py représentant l'interface d'un module écrit en C dans lequel les fonctions utilisent uniquement l'ordre des arguments.
[^] # Re: Sur quel support ?
Posté par GuieA_7 (site web personnel) . En réponse au journal recherche jeu et chat pour préados. Évalué à 4.
J'allais poser cette question aussi. Ainsi que "Faut que ça soit libre ?" & "Quel budget ?".
[^] # Re: Et toi, quel est ton avis ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 7.
En l'occurrence c'est plus un biais de confirmation ici.
Bien sûr que Go est plus performant (code natif, typage statique, parallélisme…), mais dans ce cas :
[^] # Re: Format des cartouches PNG
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche PICO-8, TIC-80 et les consoles imaginaires. Évalué à 1. Dernière modification le 27 septembre 2019 à 21:07.
D'un autre côté il faut quand même vérifier, à un moment donné, que la contrainte arbitraire 160×205px est respectée ; si on met une PNG de la taille qu'on veut on a une cartouche avec la capacité qu'on veut.
Après j'imagine qu'il y a sûrement une bonne raison (au moins à la base) pour avoir opté pour cette technique (genre ne faire qu'une seule vérification et pas deux).
[^] # Re: gardiens de la bien-pensance
Posté par GuieA_7 (site web personnel) . En réponse au journal Au revoir, LinuxFR. Évalué à 2.
Plot twist: le flic c'était Zenitram.
[^] # Re: Stats
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 1.
Ok merci d'avoir précisé ta pensée et d'avoir regardé pour Gimp.
Pour Blender en revanche je pense que c'est bien embarqué comme tu le décris.
[^] # Re: Stats
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 1.
À moins que je n'ai pas compris ce que tu appelles "embarquer", tu es es passé à côté de pleins de logiciels (typiquement écrits en C/C++) et qui embarquent Python. On pensera par exemple à Gimp et à Blender.
[^] # Re: Retour sur des grosses applications
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 1.
Ça n'est pas indéfendable de manière absolue, c'est un compromis tout à fait subjectif (que tu peux tout à fait refuser hein). Par exemple si ça provoque 0.001% (chiffre sorti de mon chapeau pour l'exemple) de bug mineurs en plus mais que ça permet d'améliorer sensiblement la beauté de l'ensemble du code (ne pas avoir à "beautifier" le code d'une bibliothèque externe que tu lis, tu te sens de base à peu près chez toi), on peut tout à fait comprendre que certains acceptent le compromis sans souci.
Après je suis aussi le premier à dire que pour du code hyper critique il vaut mieux éviter le Python (et le C)…
[^] # Re: Retour sur des grosses applications
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 1.
Tu affirmes que l'indentation en Python est une cause monumentale de bugs, mais tu ne nous dis toujours pas comment tu le sais. Si je comprends bien tu ne codes globalement qu'en C toute la journée donc ce n'est pas ton expérience personnelle ; et toujours aucun lien vers des gens qui font du Python et qui parlent de ce (soit-disant) gros problème (alors que des blogs qui se plaignent de l'absence de typage statique ou du GIL ce n'est pas ce qui manque)…
[^] # Re: Stats
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 3.
Chose amusante, Jython (implémentation de Python en environnement Java) permet le vrai parallélisme (même si évidemment il y a un "stop the world" lors du travail du GC) ; après comme ce n'est pas compatible avec les modules écrits en C pour l'implémentation la plus utilisée (CPython), je ne pense pas que grand monde s'en serve.
[^] # Re: Retour sur des grosses applications
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 3.
Sans doute… ou pas. S'il y en a des "tétra-chiées" tu ne devrais pas avoir de problème à nous en indiquer quelques uns.
Parce que des vulnérabilités dans du code C ayant mené à des soucis énormes de sécurité (entre autres) ce n'est pas difficile, il y en a beaucoup. Par exemple les différentes failles dans OpenSSL de ces dernières années (Heartbleed et compagnie) ; évidemment C est très utilisé (et pas au mêmes endroits que Python, donc difficile de comparer), et aucun langage n'empêchera jamais de coder salement etc… donc je ne vais pas tout mettre sur le dos du C. Mais l'existence de "tétra-chiées de bugs fort coûteux" est sans appel.
Reste que dire que C est plus fiable que Python pour une raison de re-formatage du code source c'est assez ridicule. J'écris du python depuis 2004 (et à temps plein de puis 2009) et j'ai du être piégé une poignée de fois par un problème d'indentation foireuse, et j'ai au pire perdu quelques minutes à trouver pourquoi mon code ne marchait pas ; ça n'a jamais donné lieu à un bug qui explose chez un utilisateur. Peut-être parce que je teste mon code, j'évite de le committer directement avoir l'avoir écrit (un buffer-overflow il faut passer à un niveau supérieur niveau test, genre fuzzing, pour les trouver efficacement, c'est très loin d'être trivial). Il y a des tas de vrais problèmes dans python, mais "ohalala j'ai copié-collé 3000 lignes de codes trouvées sur le Web, j'ai pas testé et ça me faire du caca" n'en est pas un.
[^] # Re: Pourquoi Rust ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Une exploitation massive de failles dans iOS depuis plus de 2 ans. Évalué à 3.
Hum j'ai souvenir d'une série d'articles dans LinuxMag (il y a plusieurs années) sur l'écriture d'un noyau en Ada (et notamment un passage corsé sur la gestion de la mémoire virtuelle). Tu me mets le doute du coup sur comment ça se passe avec le runtime de Ada ; il y a peut être moyen de le désactiver (comme pour la gestion des exceptions en C++).
# Éléments de réponse
Posté par GuieA_7 (site web personnel) . En réponse au message aide en assembleur quand je lance objdump -M intel -DTCs ./a.out. Évalué à 2.
Si tu veux étudier le langage assembleur pour un programme C dont tu as les sources, tu peux utiliser la sortie assembleur de ton compilateur plutôt que de désassembler un binaire (option -S de gcc il me semble).
Ça dépend de ton processeur ; sur MIPS 32 bits, toutes les instructions font 32bits par exemple (du coup pour stocker certaines constantes dans le code il faut parfois 2 instructions). Sur x86, la taille des instructions varie ; ça rend leur décodage plus complexe, mais en pratique le code binaire est souvent plus compact. De plus, il ne faut pas oublier que les x86 ont toujours gardé la compatibilité binaire ascendante, et donc ton x86 64bits comprend les instructions 8086/286/386/… et on comprend bien que les instructions du 386 ne sont pas en 64bits. L'ensemble des instructions d'un processeur est appelé ISA, et tu dois pouvoir trouver cette spec' pour le processeur qui t'intéresse.
Comment le processeur s'y retrouve-t'il ? Comme d'habitude, il lit l'OpCode en début d'instruction, il sait alors ce qu'est l'instruction, et donc sa taille. Les instructions sont chargées dans le processeur depuis le cache mémoire (qui est bien rempli depuis la RAM avec plusieurs instructions et en utilisant efficacement ton bus de 64bits).
[^] # Re: Vaguement
Posté par GuieA_7 (site web personnel) . En réponse au journal Quelqu'un est en train de spammer les serveurs SKS. Évalué à 5. Dernière modification le 06 juillet 2019 à 20:38.
Je n'ai pas tronqué "habilement" cette partie afin d'en changer le sens ; cette partie ne change absolument pas le sous-entendu de ta phrase.
Exemple:
"Par ailleurs, XXX n'est pas performant, c'est écrit en Python. Mais c'est un détail."
Bon et ben ça sous-entend clairement que le logiciel XXX est lent, et que c'est la faute (au moins en partie) de Python. Le "Mais c'est un détail" s'applique à l'ensemble le la première phrase, et n'enlève pas le sous-entendu de la première phrase.
En gros tes 2 phrases se comprennent (pour plein de gens) telle que:
"Par ailleurs, PGP n'est pas libre car c'est commercial. Mais c'est un détail."
(et donc commercial implique non-libre/propriétaire, ce qui est faux)
Et pas:
"Par ailleurs, PGP n'est pas libre, et en plus, et ceci n'a rien à voir avec le début de la phrase, c'est commercial. Mais c'est un détail."
C'est plus clair ?
[^] # Re: Vaguement
Posté par GuieA_7 (site web personnel) . En réponse au journal Quelqu'un est en train de spammer les serveurs SKS. Évalué à 10.
Attention à ne pas laisser sous-entendre que libre et commercial sont incompatibles ; le contraire de "libre" c'est "propriétaire".
[^] # Re: Captures d'écran
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Sortie de Crème CRM en version 2.0. Évalué à 3.
Vous avez raison ; l'interface a pas mal évolué (notamment avec la 1.7 sortie l'année dernière) et mon collègue qui s'occupe du site est assez débordé.
Merci beaucoup ! C'est évidemment une fierté pour nous d'arriver à développer un logiciel libre avec nos petits moyens ; ça fait plaisir de voir que des gens aiment mes dépêches (je sais qu'il est plus facile de prendre la plume quand on est mécontent).
[^] # Re: API ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Sortie de Crème CRM en version 2.0. Évalué à 3.
Le cas qu'on a pu avoir c'est par exemple un client avec un vieil ERP développé en interne et tournant sous AS400 ; l'équipe en interne impose que la communication se fasse avec un fichier plat généré toutes les nuit par l'ERP. Si on a le choix de la technique on partira évidemment plus sur des web-services.
J'aimerai beaucoup avoir l'occasion de travailler sur la communication avec d'autres logiciels libres ; en pratique ce n'est malheureusement une demande de nos clients actuels (ce qui touche à la problématique du financement des logiciels libres).
[^] # Re: API ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Sortie de Crème CRM en version 2.0. Évalué à 7.
Il n'y a pas (encore) d'API au sens Rest si c'est votre question. Il y a bien longtemps un de nos clients en voulait une rapidement, et j'avais donc fait une v0.1 ; mais finalement ledit client à changé d'avis et nous n'avons jamais eu l'occasion de tester en production et donc d'intégrer ce code.
Ils arrivent régulièrement à mes collègues qui s'occupent des intégrations client de devoir s'intégrer avec des outils maison (comme on peut s'en douter) ; et pourtant on n'a pas encore eu une vraie occasion de coder une API Rest générique. En effet parfois ces outils maison pondent des fichiers plats (qu'on va par exemple lire la nuit) ; parfois ce sont ces outils qui ont une API sur laquelle on doit s'interfacer ; et parfois mes collègues rajoutent une mini API (avec Django Rest Framework) pour les besoins spécifiques.
Donc ça arrivera soit le jour où on estimera que ça nous ferait globalement gagner du temps d'en mettre une générique (plutôt que d'en faire des had-oc), soit le jour ou un utilisateur sera prêt à investir pour (en temps/code ou en argent)—sachant que ce n'est sûrement pas énorme (mais bon comme toujours, pour faire bien, il faut un minimum de temps).
En espérant avoir répondu correctement à votre question.
[^] # Re: Ne pas effacer l'histoire, et question de monopole.
Posté par GuieA_7 (site web personnel) . En réponse au journal Service après-vente : Boulet (le dessinateur) et l'art libre. Évalué à 2.
Du coup tu dis exactement la même chose que moi, à savoir qu'"éviter d'utiliser la popularité d'un héros pour passer un message contraire" serait un prétexte pour la plupart des artistes qui auraient tenu de tels propos. Le fait qu'ils veuillent tout protéger n'ayant jamais été un problème dans mes précédents messages ; je n'ai jamais fait que pointer une certaine hypocrisie. Mais pas la peine de s'offusquer pour autant, nous sommes tous des "hypocrites", dans le sens où nous sommes plein de contradictions (pas dans le sens où nous serions malintentionnés) ; mais interroger nos contradictions est intéressant, c'est ce qui nous fait évoluer.
Je crois que c'est là le souci ; je n'ai rien demandé à personne de réel, juste posé une problématique. Il n'a jamais été question d'interroger avec une lampe braquée dans la figure (là encore mon propos était tout à fait neutre, pourquoi imaginer la pire version ?) ; tu n'as aucune idée de la façon dont je me serais adressé à un artiste réel, et tu me fais un procès d'intention.
Tu dis être dans le milieu artistique, tu t'es peut-être senti agressé par mes propos ; si c'est le cas j'en suis désolé. Mais relis mes propos, je n'ai jamais demandé à qui que ce soit de libérer quoi que ce soit, encore moins sans expliquer les conséquences d'un telle libération. Je me contente de faire et financer du code et de l'art libres en posant donc cette question "ultra délicate et personnelle" à moi-même avant tout. Mais si
"la question de la licence ne se pose pas […]", je trouve dommage que ta position sur le sujet ait l'air d'être en substance .
[^] # Re: Ne pas effacer l'histoire, et question de monopole.
Posté par GuieA_7 (site web personnel) . En réponse au journal Service après-vente : Boulet (le dessinateur) et l'art libre. Évalué à 4.
En effet on ne s'est pas compris ; mon propos est beaucoup plus neutre. Je parle de quelqu'un qui n'imagine juste pas d'utilité autre que la sienne (un peu comme un script shell personnel qu'on ne diffuse pas car trop spécifique). C'est plus clair ?
Je ne parierai pas là dessus, avec Samsung condamné pour avoir copié les bords ronds par exemple ; ce n'est pas tout à fait un style graphique, et donc je n'affirme pas catégoriquement que c'est possible, mais que c'est la tendance actuelle.
En gros tu me dis qu'on a vraiment trop de chances d'avoir quand même le droit de s'inspirer d’œuvres propriétaires ?
Comme je l'ai dit, mon test est destiné à un artiste qui dit "je libérerai bien, mais mon héros je veux contrôler ses propos" et tu l'appliques à un artiste qui dit directement/franchement qu'il ne veut rien libérer, pas étonnant qu'"il ne fonctionne pas"…
Pas la peine de rappeler à chacun de tes messages que oui la majorité des artistes veulent contrôler leur œuvre, je pense que tout le monde ici est au courant. Le commentaire auquel j'ai répondu à la base parlait de protéger un minimum de chose par une marque, tout en libérant le reste et je réfléchissais sur ce thème de mélange libre/marque, et tu t'acharnes à rappeler que des tas de gens ne veulent rien libérer du tout. C'est vrai, et personne n'a dit le contraire, mais aucun rapport avec mes messages.
[^] # Re: Ne pas effacer l'histoire, et question de monopole.
Posté par GuieA_7 (site web personnel) . En réponse au journal Service après-vente : Boulet (le dessinateur) et l'art libre. Évalué à 4.
Désolé si c'est l'impression que ça donne, mais ce n'était pas mon intention et je ne vois pas du tout de laquelle de mes phrases tu parles. Peux-tu préciser où ?
C'est vite dit ; avec la tendance actuelle de tout verrouiller au nom de la sacro-sainte propriété intellectuelle (concept au final très récent à l'échelle de l'histoire—on créait déjà des tas choses formidables avant ça) notre système a au contraire des tas de façons de nous empêcher de faire des choses. Ce qui est stupide vu que la création pure n'existe pas, et les œuvres sont toujours ce qu'elles sont uniquement grâce aux œuvres précédentes (que l'inspiration soit consciente ou non, assumée ou non).
Tu sors ma phrase de son contexte. Je parle des auteurs qui se réfugient derrière "mon personnage iconique reconnaissable par les enfants ne doit pas dire des horreurs" (et je propose de tester dans quelle mesure c'est un prétexte ou pas selon les cas), et tu m'expliques qu'il existe des auteurs qui vont dire explicitement "je ne libère rien c'est un tout" ; je le sais très bien mais en quoi ça nous avance ?
[^] # Re: Ne pas effacer l'histoire, et question de monopole.
Posté par GuieA_7 (site web personnel) . En réponse au journal Service après-vente : Boulet (le dessinateur) et l'art libre. Évalué à 6.
Il se trouve que j'ai posé la question de l'impact économique dans le premier commentaire de ce journal, donc oui je pense que la question est intéressante. Et la réponse de Boulet est "pas d'impact économique significatif".
Du coup l'aspect économique n'étant pas bloquant (selon lui), je m'intéresse à un autre aspect dans ce thread.
La plupart des artistes ne se sont sûrement pas posé la question du libre car le libre reste une philosophie/approche récente en ce qui concerne l'art. Mais ici on s'intéresse à ceux qui se sont posé la question.
Si un artiste A libère une œuvre #1 (c'est un acte volontaire) et qu'un artiste B réutilise ladite œuvre dans le respect de la licence libre pour créer une nouvelle œuvre, cette dernière est une œuvre collaborative avec pour auteurs A & B, et il n'est nullement question que ça soit caché. Ce n'est en aucun cas un plagiat, on modifie une œuvre pour en créer une nouvelle avec l'accord du créateur originel ; c'est le principe du libre.
Maintenant une licence libre peut être violée tout comme une licence propriétaire, cela n'est pas un problème spécifique au libre.
Tout dépend de ce qu'on entend par "important".
Dans un précédant débat sur l'art libre (désolé j'aurai peut-être du plus expliciter), un argument contre le libre et qui ressemble à ce qui est dit plus haut sur la protection des marques était du genre:
"J'ai créé un super-héros, CastorMan, qui a des milliers de fans et qui véhicule des valeurs positives de tolérance et d'entre-aide ; je ne veux pas que des gens puissent profiter de la notoriété de mon personnage pour diffuser des messages haineux."
Du coup, de la même manière que Firefox protège sa marque (on ne peut pas prétendre être le FireFox officiel et surfer sur sa notoriété) mais ouvre au final tout le reste, je me demande dans quel mesure un artiste serait prêt à libérer tout ce qu'il y autour de ses personnages iconiques.
Évidemment que ça poserait des soucis en pratique de gérer des licence différentes pour les personnages principaux et pour le reste ; mais je trouvais que c'était une question "philosophique" intéressante à poser à un artiste qui serait dans cette optique. Par exemple s'il refuse théoriquement de libérer une case avec un décor "passe-partout" (sans les héros dont la libération poserait problème selon lui), alors c'est que cette histoire de protection de marque/héros est un prétexte.
Désolé si je n'avais pas été clair.
[^] # Re: Ne pas effacer l'histoire, et question de monopole.
Posté par GuieA_7 (site web personnel) . En réponse au journal Service après-vente : Boulet (le dessinateur) et l'art libre. Évalué à 4.
Tu as tout à fait raison, c'est potentiellement difficile de réutiliser des bouts d'une œuvre pour en faire une autre…
…mais ça ne change rien à mon propos. Dans le cas qui nous intéresse, l'approche libre c'est de dire "Voila mon travail, vous pouvez en faire ce que vous voulez [*], ça vous sera peut-être utile" ; et dire "je ne libère pas parce que de toute les façons ne vois pas comment vous pourriez vous en resservir" est juste un prétexte. Si c'est difficilement réutilisable tant pis ; toute la beauté de la chose est que si quelqu'un trouve une façon de s'en resservir, il le pourra. Par exemple, une case de BD avec un joli décor pourrait servir de (base à une) jaquette d'album de musique.
[*] dans les limites imposées par la licence évidemment.
[^] # Re: Ne pas effacer l'histoire, et question de monopole.
Posté par GuieA_7 (site web personnel) . En réponse au journal Service après-vente : Boulet (le dessinateur) et l'art libre. Évalué à 4.
Si demain les créateurs de Firefox ferment le code source en disant que le libre c'est intéressant mais qu'il faut bien qu'ils protègent leur marque, on ne pourra pas dire qu'ils sont favorables au libre et ne font que protéger leur image.
Boulet serait-il prêt à libérer ses scénarios et le graphisme des décors, et garder le graphisme de ses héros sous licence propriétaire, afin qu'on ne puisse pas se servir de son image pour porter un autre message tout en libérant un maximum de chose ? Seul lui a la réponse évidemment (je ne vais pas faire de procès d'intention), qui permettrait de savoir à quel point il est sincère.
# Sauver les auteurs ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Service après-vente : Boulet (le dessinateur) et l'art libre. Évalué à 10.
En même temps l'art libre, de même que le logiciel libre, n'a jamais eu la prétention d'améliorer la situation (financière on imagine bien) de leurs créateurs ; le libre concerne avant tout celui qui reçoit. Le vaccin contre le cancer ne va pas non plus améliorer la situation financière des auteurs de BD, ce n'est pas anecdotique pour autant…
La question est plutôt de savoir si, dans la mesure où le business model est différent, cela peut avoir un impact négatif sur leur situation ; et vu ce qu'il avait dit auparavant ça ne serait pas étonnant qu'il le pense. Car si ce n'est pas le cas ça veut dire qu'un auteur peut sans problème donner plus/mieux à son public.