Les sources la dessus sont contradictoires. Ni toi, ni moi, ni ces sites ne sont des avocats.
Je maintiens que je suis parfaitement dans mon droit d'utiliser ces images, que LinuxFR n'est pas sujet à litige quand ces images sont en plus externes.
Le pire des cas, c'est que vous recevez une demande de suppression des ayants droits (qui se traduirait par un procès en cas de refus). Toutes actions prises avant ça prennent source dans une paranoïa et sont du zèle.
Explique moi en quoi littéralement tout les sites journalistiques existant ont le droit d'héberger et de distribuer ces images, mais moi je n'ai pas le droit de faire du hotlinking.
Il ne semble pas que les assets graphiques soient libres de droit, donc le logo n'est pas soumis à la licence CC-By-SA, et l'auteur du post n'en possède pas les droits.
Et cela ne pose pas problème justement grace au hotlinking et au droit de citation que tu cites :)
Ce qui est sous licence CC-By-SA, c'est ce que j'ai écrit. Donc quand j'écris :
![alt][external link]
L'image pointée n'est pas soumise à la licence CC-By-SA. Sinon tout les articles de ce site qui diffuse le logo de Chrome, Firefox, Android, etc… sont des violations. C'est le principe du hotlinking.
on remplit les trois conditions : tu savais, tu l'as écrit ici, et LinuxFr.org est au courant
Les images que j'ai lié n'enfreignent pas le droit d'auteur. Ces images elles même étaient hébergées par des sites journalistiques qui n'ont pas en leur possession de licence d'utilisation provenant de la Toei, c'est le droit de citation qui est exercé ici.
on les bloque au besoin
Ici, je réfute le besoin de les bloquer. C'est pour moi du zèle, voir même irrespectueux de l'hommage que je voulais faire. En fait, c'est de la parano rien de plus.
et ceux qui disent « ça n'arrive jamais » ne sont pas les gens qui gèrent les problèmes
Bien belle phrase pour se dédouaner qui montre encore votre paranoïa. Le droit de citation existe, le hotlinking n'est pas une infraction du droit d'auteur. Non, je vous garanti bien que la Toei ne va pas vous mettre un procès dans la tronche pour l'utilisation de 3 images qui citent la source. Ou alors il faut faire fermer tout les sites journalistiques, reddit, youtube, etc…
Votre position sur le sujet est juste ridicule.
La chose à faire ici, qui serait respectueuse, vu qu'aucune infraction n'a été commise (ou alors, merci de me le prouver), serait de restaurer les-dites images.
Le hotlinking (utiliser une balise <img/> dont le src pointe vers une resource externe) n'est pas une violation de copyright.
Le contenu que j'ai soumis n'enfreint aucun copyright, je comprend pas pourquoi il s'est fait éditer… Surtout quand le-dit contenu cite la source/l'auteur original. Vous avez tant peur que ça d'un procès de la Toei que l'on ne peut plus rendre hommage à un artiste ?
Si LinuxFR parse le markdown et va wget les images pour les copier sur leur serveurs, c'est une autre histoire, et c'est très bizarre de faire ça.
Vous avez vérifié que toutes les images diffusées sur le site (logos de projets même libre, photo de profil de tout les utilisateurs, …) n'enfreignent aucun copyright ?
Bah du coup on est d'accord. Tu répètes ce que j'ai dit.
En tant que développeur d'application qui n'a pas la popularité d'un Firefox ou vim, et donc personne d'autre que moi ne prendra le temps de faire les paquets, je vais pas me faire chier à distribuer sur 50 plateformes différentes et faire un tgz.
Si tu lis tout les commentaires, tu verra que j'ai déjà évoqué cette idée de mainteneur qui créent le paquet pour leur distribution.
Tu verras aussi qu'il a été mentionné que ces derniers ne prendront le temps de le faire que pour les applications ayant déjà beaucoup d'utilisateurs. Tout le monde n'est pas Firefox ou vim.
Le premier arbre de commentaire est à propos de AppData, ProgramData, ProgramFiles, et le registre.
Je considère ces dossiers comme l'équivalent Windows des dossier XDG.
Comme je l'ai dit, ces problèmes d'intégrations existent aussi sous Linux, pas mal d'applications ne respectent pas XDG et foutent tout et n'importe quoi dans le $HOME.
Quand on voit le merdier que foutent les devs sous Fenêtre et Pomme…
T'as des exemples concrets à donner ? Sous Windows, chacune de mes applications a son propre dossier dans lequel elle mes ses dépendances (le fameux Program Files ou pour Scoop, $HOME/scoop/apps/<application>, ou pour Steam son dossier steamapps).
Je ne vois pas de quel merdier tu parles.
savoir l’intégrer proprement à un système est une autre chose qui ne s’improvise pas non plus.
On ne parle pas d'intégration ici, mais de distribution. Parce que le problème d'intégration au système, il est autant présent sous Windows, Mac et les distributions Linux/BSD.
Contrairement aux systèmes fermés, on ne te demande pas de considérer « chaque variante de » mais de confier aux mainteneurs des distributions.
J'ai pas dit le contraire. Cependant les mainteneurs des distributions, ils ont que 2 bras et 24h dans une journée. Si ton application n'est pas populaire, tu peux courir pour que quelqu'un fasse le travail. Et si tu veux simplifier la vie de tes utilisateurs, tu vas donc devoir le faire toi même.
Mais comme c'est impossible de satisfaire tout le monde, tu va faire un paquet pour Ubuntu, un pour Fedora, et les autres vont devoir se démerder.
Mais c’est trop dur, on veut refaire sa jungle façon Python
Le soucis que pose Snap et Flatpak, c'est qu'ils viennent s'ajouter au gestionnaire de paquets de la distribution (apt, yum, …). Cependant, il existe des distributions qui utilisent ces gestionnaires de paquets sans apt/yum/… Comme ElementaryOS en fait.
Quel est le problème ici ?
Comparer un gestionnaire de paquet qui embarque un runtime sur lequel les applications peuvent se reposer, peu importe la distribution, avec l'état de l'art de la gestion de paquet sous Python, c'est de la mauvaise foie. C'est comme comparer des patates et des tomates. C'est tout simplement pas la même chose, pas le même cas d'usage.
Sinon, au passage, il y en a qui se chargent de leur DEB/RPM en n’ayant qu’une seule variante générique ; et ce ne sont pas que de petits projets.
Montre les. Car déjà, rien qu'entre Debian et Ubuntu, les noms de paquets ne sont pas forcément les mêmes. Donc un DEB pour Debian ne va pas forcément fonctionner magiquement sous Ubuntu.
On n’est pas sorti de l’auberge si les gens qui disent aimer/défendre/faire du libre répandent de fausses informations.
Il ne faut pas confondre "avis avec lequel je suis en désaccord" et "fausse information".
Aussi, je n'ai jamais dit aimer/défendre/faire du libre. Et je n'ai jamais dit le contraire non plus. Cela n'a rien à voir avec le débat. Et c'est qui "on" dans l'histoire ?
De l'autre, pour beaucoup de logiciels bien implantés il me semblait que c'était plutôt les communautés des distributions qui se chargeaient du packaging, non?
Oui mais ici, l'auteur du post accuse les développeurs de le forcer à utiliser Snap, quand il devrait accuser les mainteneurs des distributions de ne pas fournir de paquets.
Pardon, que dis-je. Il devrait plutôt respecter l'esprit du libre et faire le paquet lui même !
Du point de vue du développeur, si je veux distribuer mon application sous Windows, un ZIP ça suffit, mais idéalement je génère un installeur *.msi.
Pour Mac, je fais un *.dmg et basta.
Pour Linux, je dois faire un *.deb pour chaque variante de Debian qui a décidé de nommer ses paquets différemment, un *.rpm pour chaque variante de RHEL, tester mon application sur chacune de ces distributions pour vérifier qu'elle est compatible avec les versions des libs présentes sur le système, etc.
Ou alors, je ne distribue pas mon application sur Linux et tu te démerdes. A la limite je veux bien te filer un *.tar.gz qui contient toutes les dépendances que tu va pouvoir extraire dans ton /opt.
Ah, tiens, c'est plus ou moins ce que Snap et Flatpak font? Me fournir un environnement commun cross-distribution pour que je puisse distribuer mon application au plus grand nombre sans me soucier des millions de distributions Linux qui existent ? Bon ok, je veux bien faire un paquet Snap ou Flatpak en plus, mais c'est vraiment parce que je suis gentil hein.
Il y a 20 ans, les gens aimaient bien se plaindre que les développeurs d'applications ne distribuaient pas un port pour Linux.
Maintenant, les gens aiment se plaindre quand les développeurs le font mais pas avec leur solution favorite.
Je crois qu'en fait, les gens aiment juste se plaindre.
Alors pas exactement. Tu as besoin d'un fichier shipp.json dans le dépôt que tu cible en tant que dépendance pour pouvoir le compiler.
Ce n'est pas un "build system", le fichier shipp.json indique la commande de build et install, donc tu peux utiliser ce que tu veux: CMake, Ninja, Meson, … D'ailleurs, Shipp est écrit en Rust, et son shipp.json indique la commande cargo build et cargo install, donc ce n'est pas limité à C/C++.
Dans mes projets C/C++ j'avais pour habitude d'utiliser CMake et de add_subdirectory un git submodule pour gérer mes dépendances directes. Pour les dépendances transitive, on se retrouve avec des nested git submodule, et de la duplication de build à tord et à travers, ça devient très vite un cauchemar.
La, shipp va aller git clone/git pull les répos qui vont bien dans .shipp/deps/<dep name> et les installer dans .shipp/dist. On se retrouve donc avec un dossier .shipp/dist qui a les dossiers include, lib, bin, share, etc… que tu peux utiliser pour configurer correctement les flags -I et -L de ton compilateur par exemple.
Shipp au final, c'est juste ça : récupérer les dépendances, utiliser leur build system sans avoir de la grosse plomberie a faire pour l'intégrer au tient, compiler tout ça et compiler ton projet avec ton propre build system aussi.
C'est plutôt "n'attend pas que ce soit complètement parfait pour push".
Par exemple, pour aitoolkit, il me manquait une suite de test et la documentation. J'ai généré tout ça avec l'aide de Github Copilot (qui après avoir analysé mon code a pu générer tout ça à coup de TAB).
Pour Gin (le générateur de site statique), je m'en sers pour le site de Letlang (que je dois publier). C'est juste que j'ai pas finalisé la doc au delà de quelques tutoriels (pas de doc d'API par exemple), je l'ai quand même publié, mais ça ne veut pas dire qu'il n'est pas maintenu.
En fait, c'est plein de petits projets qui n'ont pas besoin de nouvelle fonctionnalité toutes les 3min (cc écosystème JS), mais si on remonte un bug, je le corrigerai. Les dépôts que je ne maintient plus je les archives sur Github.
Et le succès de mon dépôt aitoolkit (plus de 300 github stars en moins d'une journée), c'est motivant. Cette petite pépite que pas mal de monde a aimé, elle était restée sur mon PC pendant 1 an et demi !!
[^] # Re: Licence des illustrations ?
Posté par David Delassus (site web personnel) . En réponse au journal [HS] Akira Toriyama bronsonisé. Évalué à 4 (+4/-2).
https://www.cairn.info/revue-legicom-1998-1-page-119.htm
https://www.profession-audiovisuel.com/droit-courte-citation-instant-pro/
https://braun-avocat.com/le-droit-de-citation-en-matiere-audiovisuelle-a-lepreuve-du-droit-a-limage/
Les sources la dessus sont contradictoires. Ni toi, ni moi, ni ces sites ne sont des avocats.
Je maintiens que je suis parfaitement dans mon droit d'utiliser ces images, que LinuxFR n'est pas sujet à litige quand ces images sont en plus externes.
Le pire des cas, c'est que vous recevez une demande de suppression des ayants droits (qui se traduirait par un procès en cas de refus). Toutes actions prises avant ça prennent source dans une paranoïa et sont du zèle.
Explique moi en quoi littéralement tout les sites journalistiques existant ont le droit d'héberger et de distribuer ces images, mais moi je n'ai pas le droit de faire du hotlinking.
https://link-society.com - https://kubirds.com
[^] # Re: Licence des illustrations ?
Posté par David Delassus (site web personnel) . En réponse au journal [HS] Akira Toriyama bronsonisé. Évalué à 4 (+3/-1).
Rien que sur ce post https://linuxfr.org/news/sortie-de-luneos-eiskaffee
Il ne semble pas que les assets graphiques soient libres de droit, donc le logo n'est pas soumis à la licence CC-By-SA, et l'auteur du post n'en possède pas les droits.
Et cela ne pose pas problème justement grace au hotlinking et au droit de citation que tu cites :)
https://link-society.com - https://kubirds.com
[^] # Re: Licence des illustrations ?
Posté par David Delassus (site web personnel) . En réponse au journal [HS] Akira Toriyama bronsonisé. Évalué à 3 (+5/-4).
Ce qui est sous licence CC-By-SA, c'est ce que j'ai écrit. Donc quand j'écris :
L'image pointée n'est pas soumise à la licence CC-By-SA. Sinon tout les articles de ce site qui diffuse le logo de Chrome, Firefox, Android, etc… sont des violations. C'est le principe du hotlinking.
Les images que j'ai lié n'enfreignent pas le droit d'auteur. Ces images elles même étaient hébergées par des sites journalistiques qui n'ont pas en leur possession de licence d'utilisation provenant de la Toei, c'est le droit de citation qui est exercé ici.
Ici, je réfute le besoin de les bloquer. C'est pour moi du zèle, voir même irrespectueux de l'hommage que je voulais faire. En fait, c'est de la parano rien de plus.
Bien belle phrase pour se dédouaner qui montre encore votre paranoïa. Le droit de citation existe, le hotlinking n'est pas une infraction du droit d'auteur. Non, je vous garanti bien que la Toei ne va pas vous mettre un procès dans la tronche pour l'utilisation de 3 images qui citent la source. Ou alors il faut faire fermer tout les sites journalistiques, reddit, youtube, etc…
Votre position sur le sujet est juste ridicule.
La chose à faire ici, qui serait respectueuse, vu qu'aucune infraction n'a été commise (ou alors, merci de me le prouver), serait de restaurer les-dites images.
https://link-society.com - https://kubirds.com
[^] # Re: Licence des illustrations ?
Posté par David Delassus (site web personnel) . En réponse au journal [HS] Akira Toriyama bronsonisé. Évalué à 9 (+10/-3). Dernière modification le 08 mars 2024 à 20:53.
Le hotlinking (utiliser une balise
<img/>dont lesrcpointe vers une resource externe) n'est pas une violation de copyright.Le contenu que j'ai soumis n'enfreint aucun copyright, je comprend pas pourquoi il s'est fait éditer… Surtout quand le-dit contenu cite la source/l'auteur original. Vous avez tant peur que ça d'un procès de la Toei que l'on ne peut plus rendre hommage à un artiste ?
Si LinuxFR parse le markdown et va wget les images pour les copier sur leur serveurs, c'est une autre histoire, et c'est très bizarre de faire ça.
Vous avez vérifié que toutes les images diffusées sur le site (logos de projets même libre, photo de profil de tout les utilisateurs, …) n'enfreignent aucun copyright ?
https://link-society.com - https://kubirds.com
[^] # Re: Licence des illustrations ?
Posté par David Delassus (site web personnel) . En réponse au journal [HS] Akira Toriyama bronsonisé. Évalué à 5 (+4/-1). Dernière modification le 08 mars 2024 à 16:58.
A ce que je sache, LinuxFR n'héberge pas les images, elles sont toujours hébergées par les sites qui les ont originellement publié.
En tout cas, les liens que j'ai mis sont externes.
https://link-society.com - https://kubirds.com
[^] # Re: Merci
Posté par David Delassus (site web personnel) . En réponse au lien Écrire du Python comme si c'était du Elixir (ou du Erlang). Évalué à 4. Dernière modification le 11 février 2024 à 22:48.
Fun fact, les
ExceptionGroupde Python 3.11 c'est inspiré par le travail de njsmith (l'auteur initial de trio) sur trio (lesMultiErrorinitialement).Beaucoup d'améliorations de asyncio sont également inspirées de trio.
https://link-society.com - https://kubirds.com
[^] # Re: où est la suite ?
Posté par David Delassus (site web personnel) . En réponse au lien Écrire du Python comme si c'était du Elixir (ou du Erlang). Évalué à 4.
Mais moi je suis un gentil, je publie des friends links qui vous permettent de pas avoir de pub et l'article complet <3
https://link-society.com - https://kubirds.com
[^] # Re: où est la suite ?
Posté par David Delassus (site web personnel) . En réponse au lien Écrire du Python comme si c'était du Elixir (ou du Erlang). Évalué à 3.
Tu dois avoir une extension dans ton navigateur qui fait ça automatiquement.
Ces sites (scribe.rip, …) c'est de la dobe, ils mettent pas l'article complet.
https://link-society.com - https://kubirds.com
[^] # Re: où est la suite ?
Posté par David Delassus (site web personnel) . En réponse au lien Écrire du Python comme si c'était du Elixir (ou du Erlang). Évalué à 3. Dernière modification le 11 février 2024 à 22:19.
Es-ce que tu passe par dev.to ou quelque chose du genre ?
https://link-society.com - https://kubirds.com
[^] # Re: contre aussi, mais à contre-tendance de l'avenir
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 2.
ElementaryOS utilise Flatpak comme gestionnaire de paquet par défaut.
https://link-society.com - https://kubirds.com
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 4.
En plus, le tgz c'est déjà un paquet pour Slackware !
https://link-society.com - https://kubirds.com
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 4.
Bah du coup on est d'accord. Tu répètes ce que j'ai dit.
En tant que développeur d'application qui n'a pas la popularité d'un Firefox ou vim, et donc personne d'autre que moi ne prendra le temps de faire les paquets, je vais pas me faire chier à distribuer sur 50 plateformes différentes et faire un tgz.
https://link-society.com - https://kubirds.com
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 2. Dernière modification le 29 janvier 2024 à 14:56.
Si tu lis tout les commentaires, tu verra que j'ai déjà évoqué cette idée de mainteneur qui créent le paquet pour leur distribution.
Tu verras aussi qu'il a été mentionné que ces derniers ne prendront le temps de le faire que pour les applications ayant déjà beaucoup d'utilisateurs. Tout le monde n'est pas Firefox ou vim.
https://link-society.com - https://kubirds.com
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 4.
Deux de mes choses favorites dans la vie, réunie en un seul miracle ?
Merci.
https://link-society.com - https://kubirds.com
[^] # Re: Pas tous libre
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 5. Dernière modification le 29 janvier 2024 à 14:38.
https://github.com/freetocompute/kebe
https://link-society.com - https://kubirds.com
[^] # Someone is wrong on the internet
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 10. Dernière modification le 28 janvier 2024 à 23:17.
Vous commencez à casser les pieds avec votre discussion de sourd.
Personne ne contredit que le client est libre. Mais le système qui englobe le client et le serveur ne l'est pas, car le serveur ne l'est pas.
Oracle n'est pas libre, même si il existe des clients oracle libres.
Snap, qui inclus Snap Store n'est pas libre, même si il existe des clients pour le Snap Store qui sont libres.
https://link-society.com - https://kubirds.com
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 3.
Le premier arbre de commentaire est à propos de
AppData,ProgramData,ProgramFiles, et le registre.Je considère ces dossiers comme l'équivalent Windows des dossier XDG.
Comme je l'ai dit, ces problèmes d'intégrations existent aussi sous Linux, pas mal d'applications ne respectent pas XDG et foutent tout et n'importe quoi dans le
$HOME.https://link-society.com - https://kubirds.com
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 2.
Pardonne mon ignorance mais, comment font-ils pour gérer les dépendances dont les noms diffèrent ?
https://link-society.com - https://kubirds.com
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 5.
T'as des exemples concrets à donner ? Sous Windows, chacune de mes applications a son propre dossier dans lequel elle mes ses dépendances (le fameux
Program Filesou pour Scoop,$HOME/scoop/apps/<application>, ou pour Steam son dossiersteamapps).Je ne vois pas de quel merdier tu parles.
On ne parle pas d'intégration ici, mais de distribution. Parce que le problème d'intégration au système, il est autant présent sous Windows, Mac et les distributions Linux/BSD.
J'ai pas dit le contraire. Cependant les mainteneurs des distributions, ils ont que 2 bras et 24h dans une journée. Si ton application n'est pas populaire, tu peux courir pour que quelqu'un fasse le travail. Et si tu veux simplifier la vie de tes utilisateurs, tu vas donc devoir le faire toi même.
Mais comme c'est impossible de satisfaire tout le monde, tu va faire un paquet pour Ubuntu, un pour Fedora, et les autres vont devoir se démerder.
Le soucis que pose Snap et Flatpak, c'est qu'ils viennent s'ajouter au gestionnaire de paquets de la distribution (apt, yum, …). Cependant, il existe des distributions qui utilisent ces gestionnaires de paquets sans apt/yum/… Comme ElementaryOS en fait.
Quel est le problème ici ?
Comparer un gestionnaire de paquet qui embarque un runtime sur lequel les applications peuvent se reposer, peu importe la distribution, avec l'état de l'art de la gestion de paquet sous Python, c'est de la mauvaise foie. C'est comme comparer des patates et des tomates. C'est tout simplement pas la même chose, pas le même cas d'usage.
Montre les. Car déjà, rien qu'entre Debian et Ubuntu, les noms de paquets ne sont pas forcément les mêmes. Donc un DEB pour Debian ne va pas forcément fonctionner magiquement sous Ubuntu.
Il ne faut pas confondre "avis avec lequel je suis en désaccord" et "fausse information".
Aussi, je n'ai jamais dit aimer/défendre/faire du libre. Et je n'ai jamais dit le contraire non plus. Cela n'a rien à voir avec le débat. Et c'est qui "on" dans l'histoire ?
https://link-society.com - https://kubirds.com
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 3.
Sur Windows, j'utilise Scoop
https://link-society.com - https://kubirds.com
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 8. Dernière modification le 28 janvier 2024 à 14:35.
Oui mais ici, l'auteur du post accuse les développeurs de le forcer à utiliser Snap, quand il devrait accuser les mainteneurs des distributions de ne pas fournir de paquets.
Pardon, que dis-je. Il devrait plutôt respecter l'esprit du libre et faire le paquet lui même !
https://link-society.com - https://kubirds.com
# J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 10.
Du point de vue du développeur, si je veux distribuer mon application sous Windows, un ZIP ça suffit, mais idéalement je génère un installeur
*.msi.Pour Mac, je fais un
*.dmget basta.Pour Linux, je dois faire un
*.debpour chaque variante de Debian qui a décidé de nommer ses paquets différemment, un*.rpmpour chaque variante de RHEL, tester mon application sur chacune de ces distributions pour vérifier qu'elle est compatible avec les versions des libs présentes sur le système, etc.Ou alors, je ne distribue pas mon application sur Linux et tu te démerdes. A la limite je veux bien te filer un
*.tar.gzqui contient toutes les dépendances que tu va pouvoir extraire dans ton/opt.Ah, tiens, c'est plus ou moins ce que Snap et Flatpak font? Me fournir un environnement commun cross-distribution pour que je puisse distribuer mon application au plus grand nombre sans me soucier des millions de distributions Linux qui existent ? Bon ok, je veux bien faire un paquet Snap ou Flatpak en plus, mais c'est vraiment parce que je suis gentil hein.
Il y a 20 ans, les gens aimaient bien se plaindre que les développeurs d'applications ne distribuaient pas un port pour Linux.
Maintenant, les gens aiment se plaindre quand les développeurs le font mais pas avec leur solution favorite.
Je crois qu'en fait, les gens aiment juste se plaindre.
https://link-society.com - https://kubirds.com
[^] # Re: Question ?
Posté par David Delassus (site web personnel) . En réponse au lien shipp: Deadly simple package manager for your C/C++ projects, written in Rust. Évalué à 2.
Alors pas exactement. Tu as besoin d'un fichier
shipp.jsondans le dépôt que tu cible en tant que dépendance pour pouvoir le compiler.Ce n'est pas un "build system", le fichier
shipp.jsonindique la commande de build et install, donc tu peux utiliser ce que tu veux: CMake, Ninja, Meson, … D'ailleurs, Shipp est écrit en Rust, et sonshipp.jsonindique la commandecargo buildetcargo install, donc ce n'est pas limité à C/C++.Dans mes projets C/C++ j'avais pour habitude d'utiliser CMake et de
add_subdirectoryun git submodule pour gérer mes dépendances directes. Pour les dépendances transitive, on se retrouve avec des nested git submodule, et de la duplication de build à tord et à travers, ça devient très vite un cauchemar.La, shipp va aller git clone/git pull les répos qui vont bien dans
.shipp/deps/<dep name>et les installer dans.shipp/dist. On se retrouve donc avec un dossier.shipp/distqui a les dossiersinclude,lib,bin,share, etc… que tu peux utiliser pour configurer correctement les flags-Iet-Lde ton compilateur par exemple.Shipp au final, c'est juste ça : récupérer les dépendances, utiliser leur build system sans avoir de la grosse plomberie a faire pour l'intégrer au tient, compiler tout ça et compiler ton projet avec ton propre build system aussi.
https://link-society.com - https://kubirds.com
[^] # Re: Petit joueur
Posté par David Delassus (site web personnel) . En réponse au journal Combattre la procrastination en publiant mes travaux non finis. Évalué à 3. Dernière modification le 19 janvier 2024 à 21:49.
Ça, c'est la procrastination de vengeance à l'heure du coucher.
cf: https://fr.wikipedia.org/wiki/Procrastination_du_sommeil
https://link-society.com - https://kubirds.com
[^] # Re: désolé de faire le méchant
Posté par David Delassus (site web personnel) . En réponse au journal Combattre la procrastination en publiant mes travaux non finis. Évalué à 10.
Alors, pour le coup, c'est pas "push and forget".
C'est plutôt "n'attend pas que ce soit complètement parfait pour push".
Par exemple, pour aitoolkit, il me manquait une suite de test et la documentation. J'ai généré tout ça avec l'aide de Github Copilot (qui après avoir analysé mon code a pu générer tout ça à coup de TAB).
Pour Gin (le générateur de site statique), je m'en sers pour le site de Letlang (que je dois publier). C'est juste que j'ai pas finalisé la doc au delà de quelques tutoriels (pas de doc d'API par exemple), je l'ai quand même publié, mais ça ne veut pas dire qu'il n'est pas maintenu.
En fait, c'est plein de petits projets qui n'ont pas besoin de nouvelle fonctionnalité toutes les 3min (cc écosystème JS), mais si on remonte un bug, je le corrigerai. Les dépôts que je ne maintient plus je les archives sur Github.
Et le succès de mon dépôt aitoolkit (plus de 300 github stars en moins d'une journée), c'est motivant. Cette petite pépite que pas mal de monde a aimé, elle était restée sur mon PC pendant 1 an et demi !!
https://link-society.com - https://kubirds.com