Le compromis est simple: pour du libre, tu ne paies rien pour avoir le logiciel au départ. Si tu veux de la maintenance il faut passer à la caisse. Par contre, tu choisis qui tu veux pour le faire.
Avec du logiciel non libre, tu paies éventuellement pour avoir le droit d'utiliser le logiciel, et en plus si tu veux de la maintenance, tu es obligé de l'acheter au même endroit (et souvent c'est vendu ensemble).
Il faut aller voir les conférences de Stallman pour comprendre ça. Pour lui, le modèle viable c'est que tu vas payer un développeur ou une équipe pour leur faire faire des évolutions sur le code, pas pour leur acheter un produit. Tu vas donc être vraiment dans une économie de service.
Alors oui, une conséquence est qu'un chinois/grosse entreprise/… va pouvoir fabriquer des calculatrices moins cher et prendre le code de NumWorks sans contrepartie. Mais par contre, si tu trouves un bug ou si tu as besoin d'une nouvelle fonctionnalité, il ne pourra pas forcément faire grand chose pour toi car il n'aura pas la maîtrise du code.
C'est pour ça aussi que pour que ça marche, il ne devrait pas y avoir de vente liée entre le logiciel et le matériel: tu achètes ton matériel où tu veux. Et tu prends un OS déjà réalisé, ou si tu as des besoins spécifiques, tu paies un dev pour qu'il t'ajoute les morceaux qui manquent. Et tu as tout intérêt à aller voir NumWorks à ce moment là: ils connaissent le code du projet par coeur, donc en principe ils pourront te faire ta nouvelle fonction plus vite et moins cher que n'importe qui d'autre.
C'est un gros changement de modèle économique parce qu'on ne peut plus se dire "on va faire un gros développement pendant 3 ans, mais après on va vendre plein de produits et récupérer notre investissement". Du coup dans ce genre de cas on va plutôt se retrouver avec du crowdfunding, ou les gens vont devoir payer d'avance, et ou ceux qui attendent sans payer pourront bénéficier gratuitement du logiciel produit à la fin, de toutes façons. Du coup le financement va reposer uniquement sur les gens qui ont un besoin urgent et qui sont prêts à payer pour, plutôt que d'attendre que quelqu'un d'autre le fasse à leur place.
Tu l'as lu le contrat utilisateur qui est affiché au premier démarrage avant que tu puisses faire quoi que ce soit? Parce que c'est à peu près certain que tout ça était écrit clairement dedans. Et me répond pas "oui mais le texte est trop long": justement, c'est le premier truc qui doit te mettre la puce à l'oreille, ils ont un tas de choses à te faire accepter.
Alors si tu l'as pas lu, vient pas râler qu'on t'as pas prévenu et que c'était fait dans ton dos.
Ou alors on arrête d'utiliser le flow "merge requests" de Github. Par exemple, en utilisant le flow de Gerrit, qui marche vraiment pas mal et ne nécessite pas la notion de "forks" sur une même instance de l'hébergement.
Personnellement, le gros projet auquel je contribue depuis longtemps était déjà auto hébergé, et le reste n'est pas spécialement critique et donc hébergé soit sur github, soit sur gitlab, soit chez moi sur mon serveur en fonction de l'humeur du jour. Et je ne prévois pas spécialement de tout déplacer (j'ai autre chose à faire et ça n'a pas d'intérêt dans l'immédiat).
ça dépend du fabricant. Toujours aucun problème chez Sony, par exemple, qui documente le processus sur ses pages "developpeur" et fournit les outils nécessaires. Mais c'est sûr que si même les moules sur LinuxFR continuent à acheter du Samsung…
Le système de build du compilateur Go lui même dépendait à l'époque de plein de trucs téléchargés depuis code.google.com. Depuis que cette plateforme est fermée, c'est impossible de compiler les vieilles versions de Go (j'ai essayé avec la 1.3) à partir des sources d'époque (je ne sais pas s'il existe des sources modifiées pour pointer sur un dépôt toujours en ligne).
Non mais ils ont pas réglé ça chez Go encore? ça avait déjà été le gros bazar avec la fermeture de code.google.com, et ils ont recommencé avec Github ?!
Tu connaît des entreprises qui ne cherchent pas à gagner de l'argent peut-être?
C'est évident qu'ils vont aller là ou il y a des sous à gagner. Comme tout le monde. Ils peuvent le faire soit en détruisant tout sur leur passage, soit en essayant de collaborer avec le reste de l'écosystème (du technosystème?) et en construisant quelque chose de durable. En ce moment ils sont plutôt dans la deuxième approche. Ce qui n'en fait pas des bienfaiteurs de l'humanité, hein.
Je suis pas sûr que ce soit le libre qui s'est dépolitisé. Il faut bien se rappeler du fonctionnement de Github: l'hébergement est gratuit pour les projets dont le code est public. Du coup, plein de gens profitent du service sans forcément s'engager dans le logiciel libre, et même sans forcément mettre de licence sur leur code.
C'était un peu différent sur Google Code à l'époque, qui était réservé aux projets libres (ils forçaient le choix d'une licence quand on créait un projet, parmi une liste assez restreinte). Mais donc sur Github, on a plein de gens qui sont juste là pour profiter d'un dépôt git, d'un bugtracker, d'un wiki et d'un hébergement web gratuits, en échange de laisser tout le monde voir leur code. Mais sans s'engager forcément dans une démarche de logiciel libre.
Est-ce que ça peut être suffisant pour faire découvrir le logiciel libre aux gens? Peut être. Ils auront la bonne surprise d'avoir des pull requests, ou la mauvaise d'avoir des rapports de bugs agressifs de gens qui veulent pas vraiment aider mais juste se passer les nerfs.
Il y a un problème avec la monoculture Github cependant. Je travaille dans certains projets qui ont une organisation différente (pour plein de raisons, on est pas obligés d'aimer le modèle des pull requests et le bugtracker imposé par github par exemple ; mais aussi parce que "ça pue c'est pas libre"). Et on doit passer un temps conséquent à expliquer notre fonctionnement à des gens qui demandent "mais pourquoi vous n'utilisez pas Github?"
Faire un rapport de bug ou juste envoyer un mail pour demander "je suis perdu, par où je commence?" c'est déjà d'une grande aide dans ce cas. En tout cas pour les projets ou j'ai mon mot à dire, j'essaie d'être à l'écoute de ce genre de remarques. Et c'est déjà une façon de contribuer.
Le nombre de personnes qui rencontrent un problème mais pensent que les développeurs le savent et ont fait exprès de faire un truc compliqué/qui marche pas est impressionnant…
Quelqu'un (j'ai oublié dans quel projet, désolé!) a utilisé l'expression "vous êtes maintenant expert dans le fait d'être débutant". Et on a besoin de retours de gens qui se sentent perdus parce que nos documentations sont mal organisées, pour savoir quoi améliorer. Parce que nous, on sait ou chercher et on ne se rend pas compte du problème.
Linux (et d'autres aussi) utilise le nom de domaine des e-mails aussi pour faire des stats sur lesentreprises qui contribuent chez eux.
Et aupassage je rappelle que la license GPL oblige à mettre les code sources à disposition pendant 10 ans quand on distribue un programme. Donc si tu es contributeur à un projet sous GPL tu es déjà obligé d'assurer de la perrenité…
C'est bien sûr l'opération par défaut et la première dans la barre d'outils, avec 4 modes de fonctionnement différents sur le même bouton (accessibles en faisant un clic droit)
On a aussi une aide contextuelle pour ceux qui seraient perdus: mettre la souris au dessus de n'importe quel bouton du menu oud'une fenêtre et appuyer sur F1 (ou Help, si vous utilisez un clavier Atari, Sun ou Amiga qui dispose de cette touche). Et comme le reste du logiciel, cette aide est pensée pour aider à faire du dessin au pixel et pas autre chose.
J'apprécie l'existence d'une liste rouge pour les numéros de téléphone. Un principe similaire pour le whois me semble approprié: on choisit si on veut, ou pas, que l'information soit publique.
De toutes façons, pour les quelques noms de domaines (en .tk) que j'utilise, le fournisseur rend déjà ce service: c'est son nom qui apparaît dans le whois, pas le mien.
Il serait tant de s'en préoccuper. Cela dit, c'est "contre indemnisation", il va donc falloir aller indemniser tous les cessionnaires, c'est-à-dire, dans le cas d'une licence de logiciel libre, toutes les personnes ayant accepté la licence (qui leur cède plein de droits). L'indemnisation risque de coûter cher…
C'est amusant de voir tout le monde paniquer autour du RGPD alors que bien souvent on parle de choses qui n'ont rien à voir et qui étaient déjà possibles auparavant.
C'est comme ça que git fonctionne et là, gitlab n'y peut rien. Il faudra voir directement avec Linus Torvalds pourquoi il a fait ce choix pour git. Mais en tout cas ça ne va pas être simple à changer.
Dans SVN par exemple il y avait uniquement un "identifiant" sans format spécifique. Mais je suppose que dans le cas de Linux, c'est très utile de pouvoir récupérer le nom et l'e-mail de la personne qui a fait tel ou tel changement directement depuis le dépôt git, sans avoir besoin de passer par un annuaire centralisé.
En France, tu gardes le droit de paternité sur ton oeuvre, même si elle est anonyme. Donc ça ne règle pas le problème. C'est justement pour ça que Gitlab demande de renoncer à une liste de droits bien spécifiques, qui n'inclut pas le droit de paternité.
L'expérience utilisateur date de la version DOS. On aime ou on aime pas. D'un côté, ça permet de travailler en étant pleinement concentré sur ce qu'on fait et sans interférences. Mais d'un autre, il y a plein de petites choses qui ne marchent pas comme prévu (en particulier tout ce qui tourne autour du presse-papier et de la saisie de texte).
En tout cas ça n'empêcherait pas de moderniser un peu l'interface et au moins d'avoir une police de caractères proportionnelle, qui serait plus agréable.
Je travaille (entre autres) avec Exocet qui tient le blog 16 couleurs. Du coup, GrafX2 a un peu évolué depuis ces articles et les choses sont devenues un peu plus simples pour la gestion des contraintes graphiques (c'est une des nouveautés de la version 2.5).
Mais en effet, l'un des intérêts est de pouvoir travailler directement avec des filtres assez tordus, du genre "une ligne sur deux, il n'y a que 4 couleurs utilisables, et pour les autres lignes, on a 16 couleurs mais les pixels sont deux fois plus larges" (ici par exemple: http://julien-nevo.com/mahjong/ )
Plus généralement, l'idée est de travailler exclusivement avec des images palettisées et donc on va aller plus loin que GIMP sur des traitements assez spécifiques, par exemple éclaircir/assombrir une couleur ne se fait pas du tout de la même façon quand on peut faire du RGB ou quand on doit choisir parmi 16 couleurs seulement. On a donc plusieurs outils pour gérer les couleurs, en les mettant dans un ordre précis, par exemple.
Un autre aspect, c'est l'idée de contrôler individuellement chaque pixel. Les outils par défaut ne font donc pas d'antialiasing, et on a des raccourcis claviers pour se déplacer d'un pixel à l'autre de façon précise (une souris ne permet pas de le faire facilement, à moins de zoomer vraiment beaucoup et du coup de ne plus avoir de vue d'ensemble sur l'image.
Les captures d'écran insérées dans l'article montrent des images qui ont été réalisées avec GrafX2, on peut voir les versions complètes et d'autres images ici ou là. Le style est assez différent de ce qu'on fait avec GIMP, et la façon de travailler aussi.
Je peux comprendre que ça devienne irritant quand on reçoit tout le temps les mêmes critiques, qu'on sait que ça serait bien de changer, mais qu'on ne peut rien faire parce qu'il y a trop d'impacts.
Mais bon, la solution est peut-être d'ajouter une entrée dans la FAQ, dans ce cas. Au moins on a pas besoin de re-rédiger la réponse à chaque fois et on peut pointer les gens sur la réponse existante.
[^] # Re: Libre diffusion ≠ Libre
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Retour sur la licence de NumWorks. Évalué à 5.
Le compromis est simple: pour du libre, tu ne paies rien pour avoir le logiciel au départ. Si tu veux de la maintenance il faut passer à la caisse. Par contre, tu choisis qui tu veux pour le faire.
Avec du logiciel non libre, tu paies éventuellement pour avoir le droit d'utiliser le logiciel, et en plus si tu veux de la maintenance, tu es obligé de l'acheter au même endroit (et souvent c'est vendu ensemble).
[^] # Re: Libre diffusion ≠ Libre
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Retour sur la licence de NumWorks. Évalué à 8.
Il faut aller voir les conférences de Stallman pour comprendre ça. Pour lui, le modèle viable c'est que tu vas payer un développeur ou une équipe pour leur faire faire des évolutions sur le code, pas pour leur acheter un produit. Tu vas donc être vraiment dans une économie de service.
Alors oui, une conséquence est qu'un chinois/grosse entreprise/… va pouvoir fabriquer des calculatrices moins cher et prendre le code de NumWorks sans contrepartie. Mais par contre, si tu trouves un bug ou si tu as besoin d'une nouvelle fonctionnalité, il ne pourra pas forcément faire grand chose pour toi car il n'aura pas la maîtrise du code.
C'est pour ça aussi que pour que ça marche, il ne devrait pas y avoir de vente liée entre le logiciel et le matériel: tu achètes ton matériel où tu veux. Et tu prends un OS déjà réalisé, ou si tu as des besoins spécifiques, tu paies un dev pour qu'il t'ajoute les morceaux qui manquent. Et tu as tout intérêt à aller voir NumWorks à ce moment là: ils connaissent le code du projet par coeur, donc en principe ils pourront te faire ta nouvelle fonction plus vite et moins cher que n'importe qui d'autre.
C'est un gros changement de modèle économique parce qu'on ne peut plus se dire "on va faire un gros développement pendant 3 ans, mais après on va vendre plein de produits et récupérer notre investissement". Du coup dans ce genre de cas on va plutôt se retrouver avec du crowdfunding, ou les gens vont devoir payer d'avance, et ou ceux qui attendent sans payer pourront bénéficier gratuitement du logiciel produit à la fin, de toutes façons. Du coup le financement va reposer uniquement sur les gens qui ont un besoin urgent et qui sont prêts à payer pour, plutôt que d'attendre que quelqu'un d'autre le fasse à leur place.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 2.
Tu l'as lu le contrat utilisateur qui est affiché au premier démarrage avant que tu puisses faire quoi que ce soit? Parce que c'est à peu près certain que tout ça était écrit clairement dedans. Et me répond pas "oui mais le texte est trop long": justement, c'est le premier truc qui doit te mettre la puce à l'oreille, ils ont un tas de choses à te faire accepter.
Alors si tu l'as pas lu, vient pas râler qu'on t'as pas prévenu et que c'était fait dans ton dos.
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 3.
Ou alors on arrête d'utiliser le flow "merge requests" de Github. Par exemple, en utilisant le flow de Gerrit, qui marche vraiment pas mal et ne nécessite pas la notion de "forks" sur une même instance de l'hébergement.
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 2.
Personnellement, le gros projet auquel je contribue depuis longtemps était déjà auto hébergé, et le reste n'est pas spécialement critique et donc hébergé soit sur github, soit sur gitlab, soit chez moi sur mon serveur en fonction de l'humeur du jour. Et je ne prévois pas spécialement de tout déplacer (j'ai autre chose à faire et ça n'a pas d'intérêt dans l'immédiat).
[^] # Re: Clone ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal ReactOS s'auto-compile !. Évalué à 3.
On ne sait pas, du coup. Les résultats de l'audit n'ont pas été publiés (bon, on peut supposer que si c'était 100% propre, ils l'auraient dit…)
[^] # Re: Bravo
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal ReactOS s'auto-compile !. Évalué à 4.
ça dépend du fabricant. Toujours aucun problème chez Sony, par exemple, qui documente le processus sur ses pages "developpeur" et fournit les outils nécessaires. Mais c'est sûr que si même les moules sur LinuxFR continuent à acheter du Samsung…
[^] # Re: Go et import path
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 5.
Le système de build du compilateur Go lui même dépendait à l'époque de plein de trucs téléchargés depuis code.google.com. Depuis que cette plateforme est fermée, c'est impossible de compiler les vieilles versions de Go (j'ai essayé avec la 1.3) à partir des sources d'époque (je ne sais pas s'il existe des sources modifiées pour pointer sur un dépôt toujours en ligne).
[^] # Re: Question naïve
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal ReactOS s'auto-compile !. Évalué à 8.
L'intérêt est le même que d'utiliser Linux par rapport à un autre UNIX propriétaire et dont les sources ne sont pas publiées :)
[^] # Re: Go et import path
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 4.
Non mais ils ont pas réglé ça chez Go encore? ça avait déjà été le gros bazar avec la fermeture de code.google.com, et ils ont recommencé avec Github ?!
Je suis déçu…
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 5.
Tu connaît des entreprises qui ne cherchent pas à gagner de l'argent peut-être?
C'est évident qu'ils vont aller là ou il y a des sous à gagner. Comme tout le monde. Ils peuvent le faire soit en détruisant tout sur leur passage, soit en essayant de collaborer avec le reste de l'écosystème (du technosystème?) et en construisant quelque chose de durable. En ce moment ils sont plutôt dans la deuxième approche. Ce qui n'en fait pas des bienfaiteurs de l'humanité, hein.
[^] # Re: Github n'est pas libre…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à -3.
ça a bien changé chez Microsoft ces derniers temps.
# Politisation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Microsoft rachète Github. Évalué à 8.
Je suis pas sûr que ce soit le libre qui s'est dépolitisé. Il faut bien se rappeler du fonctionnement de Github: l'hébergement est gratuit pour les projets dont le code est public. Du coup, plein de gens profitent du service sans forcément s'engager dans le logiciel libre, et même sans forcément mettre de licence sur leur code.
C'était un peu différent sur Google Code à l'époque, qui était réservé aux projets libres (ils forçaient le choix d'une licence quand on créait un projet, parmi une liste assez restreinte). Mais donc sur Github, on a plein de gens qui sont juste là pour profiter d'un dépôt git, d'un bugtracker, d'un wiki et d'un hébergement web gratuits, en échange de laisser tout le monde voir leur code. Mais sans s'engager forcément dans une démarche de logiciel libre.
Est-ce que ça peut être suffisant pour faire découvrir le logiciel libre aux gens? Peut être. Ils auront la bonne surprise d'avoir des pull requests, ou la mauvaise d'avoir des rapports de bugs agressifs de gens qui veulent pas vraiment aider mais juste se passer les nerfs.
[^] # Re: Merci!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Discussion sur les objectifs de la communauté KDE. Évalué à 8.
Il y a un problème avec la monoculture Github cependant. Je travaille dans certains projets qui ont une organisation différente (pour plein de raisons, on est pas obligés d'aimer le modèle des pull requests et le bugtracker imposé par github par exemple ; mais aussi parce que "ça pue c'est pas libre"). Et on doit passer un temps conséquent à expliquer notre fonctionnement à des gens qui demandent "mais pourquoi vous n'utilisez pas Github?"
[^] # Re: Merci!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Discussion sur les objectifs de la communauté KDE. Évalué à 6.
Faire un rapport de bug ou juste envoyer un mail pour demander "je suis perdu, par où je commence?" c'est déjà d'une grande aide dans ce cas. En tout cas pour les projets ou j'ai mon mot à dire, j'essaie d'être à l'écoute de ce genre de remarques. Et c'est déjà une façon de contribuer.
Le nombre de personnes qui rencontrent un problème mais pensent que les développeurs le savent et ont fait exprès de faire un truc compliqué/qui marche pas est impressionnant…
Quelqu'un (j'ai oublié dans quel projet, désolé!) a utilisé l'expression "vous êtes maintenant expert dans le fait d'être débutant". Et on a besoin de retours de gens qui se sentent perdus parce que nos documentations sont mal organisées, pour savoir quoi améliorer. Parce que nous, on sait ou chercher et on ne se rend pas compte du problème.
[^] # Re: nostalgie
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche GrafX2 enfin en version 2.5. Évalué à 5.
Je mentionne au passage que Autodesk Animator a lui aussi vu ses sources publiées et attend de subir le même sort que GrafX2: https://github.com/AnimatorPro/Animator-Pro
Il y a aussi VGAPaint 386 qui est à peu près dans la même situation.
[^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 0.
Linux (et d'autres aussi) utilise le nom de domaine des e-mails aussi pour faire des stats sur lesentreprises qui contribuent chez eux.
Et aupassage je rappelle que la license GPL oblige à mettre les code sources à disposition pendant 10 ans quand on distribue un programme. Donc si tu es contributeur à un projet sous GPL tu es déjà obligé d'assurer de la perrenité…
[^] # Re: Sympa !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche GrafX2 enfin en version 2.5. Évalué à 4.
C'est bien sûr l'opération par défaut et la première dans la barre d'outils, avec 4 modes de fonctionnement différents sur le même bouton (accessibles en faisant un clic droit)
On a aussi une aide contextuelle pour ceux qui seraient perdus: mettre la souris au dessus de n'importe quel bouton du menu oud'une fenêtre et appuyer sur F1 (ou Help, si vous utilisez un clavier Atari, Sun ou Amiga qui dispose de cette touche). Et comme le reste du logiciel, cette aide est pensée pour aider à faire du dessin au pixel et pas autre chose.
[^] # Re: Pour les projets open-source
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 2.
J'apprécie l'existence d'une liste rouge pour les numéros de téléphone. Un principe similaire pour le whois me semble approprié: on choisit si on veut, ou pas, que l'information soit publique.
De toutes façons, pour les quelques noms de domaines (en .tk) que j'utilise, le fournisseur rend déjà ce service: c'est son nom qui apparaît dans le whois, pas le mien.
[^] # Re: Github et tout les autres....
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 4.
En fait c'est indépendant du RGPD, il existe déjà dans le droit d'auteur un droit de retrait et un droit de repentir.
https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006069414&idArticle=LEGIARTI000006278894
Il serait tant de s'en préoccuper. Cela dit, c'est "contre indemnisation", il va donc falloir aller indemniser tous les cessionnaires, c'est-à-dire, dans le cas d'une licence de logiciel libre, toutes les personnes ayant accepté la licence (qui leur cède plein de droits). L'indemnisation risque de coûter cher…
C'est amusant de voir tout le monde paniquer autour du RGPD alors que bien souvent on parle de choses qui n'ont rien à voir et qui étaient déjà possibles auparavant.
[^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 4.
C'est comme ça que git fonctionne et là, gitlab n'y peut rien. Il faudra voir directement avec Linus Torvalds pourquoi il a fait ce choix pour git. Mais en tout cas ça ne va pas être simple à changer.
Dans SVN par exemple il y avait uniquement un "identifiant" sans format spécifique. Mais je suppose que dans le cas de Linux, c'est très utile de pouvoir récupérer le nom et l'e-mail de la personne qui a fait tel ou tel changement directement depuis le dépôt git, sans avoir besoin de passer par un annuaire centralisé.
[^] # Re: Git
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 3.
En France, tu gardes le droit de paternité sur ton oeuvre, même si elle est anonyme. Donc ça ne règle pas le problème. C'est justement pour ça que Gitlab demande de renoncer à une liste de droits bien spécifiques, qui n'inclut pas le droit de paternité.
[^] # Re: Ca semble vraiment sympa
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche GrafX2 enfin en version 2.5. Évalué à 3.
L'expérience utilisateur date de la version DOS. On aime ou on aime pas. D'un côté, ça permet de travailler en étant pleinement concentré sur ce qu'on fait et sans interférences. Mais d'un autre, il y a plein de petites choses qui ne marchent pas comme prévu (en particulier tout ce qui tourne autour du presse-papier et de la saisie de texte).
En tout cas ça n'empêcherait pas de moderniser un peu l'interface et au moins d'avoir une police de caractères proportionnelle, qui serait plus agréable.
[^] # Re: Sympa !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche GrafX2 enfin en version 2.5. Évalué à 8. Dernière modification le 25 mai 2018 à 12:54.
Je travaille (entre autres) avec Exocet qui tient le blog 16 couleurs. Du coup, GrafX2 a un peu évolué depuis ces articles et les choses sont devenues un peu plus simples pour la gestion des contraintes graphiques (c'est une des nouveautés de la version 2.5).
Mais en effet, l'un des intérêts est de pouvoir travailler directement avec des filtres assez tordus, du genre "une ligne sur deux, il n'y a que 4 couleurs utilisables, et pour les autres lignes, on a 16 couleurs mais les pixels sont deux fois plus larges" (ici par exemple: http://julien-nevo.com/mahjong/ )
Plus généralement, l'idée est de travailler exclusivement avec des images palettisées et donc on va aller plus loin que GIMP sur des traitements assez spécifiques, par exemple éclaircir/assombrir une couleur ne se fait pas du tout de la même façon quand on peut faire du RGB ou quand on doit choisir parmi 16 couleurs seulement. On a donc plusieurs outils pour gérer les couleurs, en les mettant dans un ordre précis, par exemple.
Un autre aspect, c'est l'idée de contrôler individuellement chaque pixel. Les outils par défaut ne font donc pas d'antialiasing, et on a des raccourcis claviers pour se déplacer d'un pixel à l'autre de façon précise (une souris ne permet pas de le faire facilement, à moins de zoomer vraiment beaucoup et du coup de ne plus avoir de vue d'ensemble sur l'image.
Les captures d'écran insérées dans l'article montrent des images qui ont été réalisées avec GrafX2, on peut voir les versions complètes et d'autres images ici ou là. Le style est assez différent de ce qu'on fait avec GIMP, et la façon de travailler aussi.
[^] # Re: Journal ou dépêche
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les serveurs de clefs incompatibles avec le règlement général sur la protection des données ?. Évalué à 2.
Je peux comprendre que ça devienne irritant quand on reçoit tout le temps les mêmes critiques, qu'on sait que ça serait bien de changer, mais qu'on ne peut rien faire parce qu'il y a trop d'impacts.
Mais bon, la solution est peut-être d'ajouter une entrée dans la FAQ, dans ce cas. Au moins on a pas besoin de re-rédiger la réponse à chaque fois et on peut pointer les gens sur la réponse existante.