Pour Cosmoe, une partie du code devra être modifiée pour fournir les mêmes APIs de façons différente. Par exemple, les BMessages et une grande partie du Media Kit sont implémenté dans Haiku via les "ports", une IPC qui n'existe pas dans POSIX. Mais il est possible de réaliser la même chose en utilisant d'autres IPCs. On est curieux de voir ce que cela donnera au niveau des performances.
D'autres choses sont et resteront impossibles sur un noyau Linux, par exemple la possibilité d'ouvrir un fichier en connaissant uniquement son numéro d'inode (ce qui est possible dans l'API de BeOS mais un gros trou de sécurité).
La notion de window manager est plus ou moins présente. Il ne s'agit pas d'un exécutable séparé, mais plutôt d'un add-on du serveur graphique (appelé "decorator"). Cela dit, l'un ou l'autre choix est valable et n'a pas vraiment d'influence sur l'API publique.
Pour les drivers, en dehors du problème des licences, les deux gros soucis du côté de Linux sont que le code est souvent assez peu lisible (peu de commentaires, etc), et que les API internes ont tendance à beaucoup changer d'une version à l'autre. FreeBSD est, en comparaison, relativement stable, ce qui nous permet de suivre plus facilement leurs évolutions.
On regarde quand même du côté de Linux, par exemple pour les drivers graphiques. Supposément, Gallium3D permet d'avoir des drivers en userland, portables d'un OS à l'autre, mais ça n'a pas l'air d'avoir vraiment marché comme ça. On va peut-être s'inspirer de ce qu'on fait FreeBSD ou DragonFlyBSD pour récupérer les pilotes Linux.
En ce qui concerne les licences, d'une part, certains pilotes Linux sont sous licence BSD, ce qui nous va très bien (par exemple pour les cartes graphiques Intel, il me semble). D'autre part, même si un pilote est sous GPL, il peut être compilé indépendament du noyau et installé séparément, donc ce ne serait pas forcément un problème (l'avantage d'avoir une ABI propre et stable pour les pilotes de périphériques ;) ).
Tu installes mupdf et tu pourras utiliser des commandes vim du type 42g pour aller à la page 42 ou /mot pour chercher un mot (puis n pour passer au résultat suivant). Je ne peux plus m'en passer pour naviguer dans des PDFs.
C'est assez peu mentionné, mais les "anciens" compteurs électroniques (la génération avant Linky) permettait de récupérer ces infos directement chez soit, via un port série situé directement sur le compteur. Pourquoi il faudrait envoyer cette information au fournisseur d'énergie puis… leur demander pour y avoir accès? (accès qu'ils pourraient très bien rendre payant, d'ailleurs).
Donc le côté éducation/information, ça existait déjà, mais ça n'intéressait pas grand monde.
L'intérêt du relevé heure par heure, c'est que le fournisseur d'énergie va pouvoir facturer ça comme il veut (par exemple Direct Energie propose des heures "super creuses" à certaines périodes). On est plus limité à un modèle heures pleines/heures creuses avec des horaires fixes imposés par le distributeur d'énergie.
C'est rigolo 3 minutes mais pas terrible pour communiquer. J'aurais préféré un site plus classique, avec quelques images des années précédentes, ce genre de choses.
Je dirais bien d'aller voir du côté de Jam (la version de Perforce, celle de Boost, celle de Freetype ou celle de Haiku), si c'était pas un outil non maintenu avec 3 forks incompatible… C'est dommage, parce que c'est un bon remplacement de make, avec la possibilité de définir des règles génériques, qui conviendrait pas mal pour ce genre d'usage.
Alors je dois prendre la défense de CMake sur ce point: il y a bien une méthode standard pour la prise en charge des dossiers d'installation, c'est GNUInstallDirs. Le problème, c'est que c'est un ajout relativement récent (ça fait quelques années quand même) et que beaucoup de projets ne l'utilisent pas et codent tout en dur. Et quand c'est utilisé, ça marche tout aussi bien que les autotools (et je dis ça en ayant packagé pas mal de choses pour Haiku, qui fait des trucs bien plus tordus que slackware en terme de chemin standardisés pour les bibliothèques, les manpages, …)
Donc ce n'est pas vraiment la faute de l'outil, mais plutôt d'une mauvaise utilisation (bon et aussi du fait que les dévs de CMake ont pendant quelques temps "oublié" de documenter GNUInstallDirs…
Il y a aussi toute la gestion du packaging (avec CPack) qui de mon expérience, fonctionne plutôt bien, pour générer des tarballs. Et il y a le support de la compilation croisée.
La vraie raison c'est qu'il y a des distributions Linux qui vont gérer la compilation et le packaging. Donc peu de projets ont besoin de le faire d'eux-même.
Non mais RMS plus personne en a grand chose à faire de ce qu'il raconte. Il y a plein d'autres organisations que la FSF qui font la promotion du libre plus efficacement et de façon pertinente. Va voir la SFC ou la FSFE par exemple.
Je vois les choses d'une façon un peu plus positive: le logiciel libre progresse plus vite que les notions d'éthique qui y étaient souvent associées. ça ne veut pas dire que la partie éthique régresse, au contraire.
Je précise que la communauté cmake (et son canal IRC) est pas mal réactive et disponible pour faire les modifications quand c'est nécessaire. Si tu n'es pas forcé de supporter de vieilles versions de cmake, tu pourras donc obtenir de l'aide pour régler ces problèmes, et s'il y a lieu, ce sera intégré dans cmake directement.
Je mentionne aussi au passage le très pratique cpack, qui permet de générer un .deb, un .rpm et/ou un installeur windows sans trop s'embêter. Mais peut être pas encore les .apk (ce n'est pas trop compliqué d'ajouter le support d'un nouveau format de distribution à cpack, cela dit…)
Je plussoie complètement l'utilisation de ninja. Juste pour le plaisir de le lancer une deuxième fois quand le build est fini et de le voir dire tout de suite "nothing to do". Sur un projet comme WebKit, make dans la même situation mets chez moi presque une minute pour arriver à la même conclusion.
Autres avantages:
- Pas besoin de choisir un -j à la main comme avec make, ninja surveille le system load et s'ajuste tout seul (en tenant compte de la charge CPU effective, donc il lancera plus de jobs en parallèle si la compilation est limitée par les accès disques, et moins si elle est limitée par le CPU ou si on fait autre chose sur la machine pendant ce temps).
- Affichage correct de la sortie de la compilation, sans mélanger la sortie de différent threads
- Affichage du nombre de cibles à compiler, ce qui permet de savoir où on en est dans le build du projet
Tu peux expliquer dans ce cas, quel est l'intérêt de faire du libre si on ne veut rien gérer? J'ai un peu de mal à voir ce que ça peut apporter dans ce cas?
Certes. Tu peux faire un "lancer de code" avec une licence sur Github et on en parle plus. Mais dans ce cas il ne faut pas s'attendre à avoir automagiquement des retours positifs et plein de gens qui contribuent. Je suis d'accord, c'est quand même du libre on a rien à reprocher et c'est déjà très bien.
Mais si on veut profiter des retours de la communauté, des contributions d'autres gens, etc, il faut s'investir un peu plus que ça. ça n'est pas nécessaire, mais ça peut être une bonne justification pour faire du logiciel libre.
Les bugs ne sont jamais "hyper évidents". Je suis dev, je teste mon code autant que je peux mais j'ai pas un temps infini, et dans la plupart des projets il n'y a pas d'équipe QA. Donc c'est souvent moins léché qu'un truc développé correctement par une entreprise (on essaie d'améliorer ça mais c'est loin d'être facile).
Donc, contribue: plains toi que la doc est moisie, que ça plante dans tous les sens et que ça tient pas la charge. Avec des exemples précis. Y'a des chances que tu tombes sur un dev qui sera content de t'aider à régler les problèmes (c'est la contrepartie de ne pas avoir d'équipe QA ou support: tu as une ligne directe pour discuter avec les devs du projet, alors profites-en).
ça me rappelle les histoires avec XChat qui a voulu faire payer les binaires Windows. Sauf que c'est un logiciel libre et qu'une autre personne (silverex) fournissait déjà gratuitement les dits binaires. ça s'est mal fini et ça a forké, et maintenant tout le monde utilise hexchat à la place.
Ce modèle ne me semble pas être le plus malin. Je me dirigerais plus volontiers vers la vente de support, et éventuellement le financement du développement de nouvelles fonctionnalités. Faire payer le travail des devs plutôt que le produit fini, donc.
Si, mettre du code sous licence libre a un coût. Tu ne peux pas le nier sinon ça va jamais marcher en entreprise. Par contre, tu peux le justifier et le "vendre": expliquer les bénéfices (en termes d'image, de contributions externes, etc) et montrer que finalement, le coût initial n'est pas si important que ça en regard.
Mais si tu essaies de faire du libre sans investir sérieusement dedans, ça ne marchera pas. Et le décideur pressé va retenir ça: "le libre, ça marche pas on a essayé". Ne gâche pas ta chance et fait les choses proprement dès le début, merci :)
ça va te coûter plus cher de maintenir ton code, qu'à quelqu'un d'autre de faire un fork et de passer un peu de temps à le nettoyer. Et en plus le fork sera 10 fois moins lourd, aura moins de bugs, etc.
Je ne vois pas comment cette recette peut être gagnante.
On a aussi l'inverse, des gens qui disent "je publierai mon code quand il sera propre et fini". Et ça n'arrive souvent jamais.
Donc oui, merci aux gens qui publient leur code, même sale, même chiant à compiler, même pas fini, même si c'est un truc qui n'a pas servi depuis 15 ans (coucou Autodesk Animator). C'est toujours mieux que de repartir de rien.
ça semble normal pour n'importe quel projet, hein. Si tu ne fais pas ça, un contributeur de ton projet peut venir 15 ans après et dire "hey j'ai changé d'avis, vous pouvez plus utiliser mon code". Ou si tu décides un jour de changer la licence pour les versions futures, tu dois contacter tous les contributeurs un par un pour demander s'ils sont d'accord. Ce qui est un gros bazar sur un projet comme OpenOffice, ou tu vas probablement te retrouver avec des adresses mail qui marchent plus, etc.
Donc la solution, c'est de faire signer un CLA, ou chaque contributeur dit "ok, si vous voulez changer la licence dans le futur, je dis tout de suite que je suis d'accord". ça semble être la moindre des précautions à prendre pour que la chose reste gérable.
D'autres cas:
* Le projet utilise du code GPL et est donc obligé de fournir toutes ses sources à ses clients, mais sans avoir envie que les gens se les approprient,
* Un développeur a bien envie de publier le code, mais sans avoir forcément le temps de le faire correctement,
* Un développeur a senti le vent tourner, et décide de publier les sources de son projet avant qu'il soit annulé et que tout parte à la poubelle (ça s'est produit par exemple pour Tracker, l'explorateur de fichiers de BeOS)
Parfois plus simplement, des gens ont entendu parler du logiciel libre et se disent "trop bien, on a juste à publier nos sources sur un serveur FTP et plein de gens vont venir travailler gratuitement pour nous" ou un truc de ce genre. Parfis au départ il y a quelqu'un qui a essayé de vendre le logiciel libre à son boss, mais le message n'est pas complètement passé…
De façon générale ça peut être plein de sortes de malentendus de ce genre qui aboutissent à un compromis bizarre. Sans forcément de mauvaises intentions pour autant.
[^] # Re: Content, enfin presque :)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 17 ans. Évalué à 3.
Pour Cosmoe, une partie du code devra être modifiée pour fournir les mêmes APIs de façons différente. Par exemple, les BMessages et une grande partie du Media Kit sont implémenté dans Haiku via les "ports", une IPC qui n'existe pas dans POSIX. Mais il est possible de réaliser la même chose en utilisant d'autres IPCs. On est curieux de voir ce que cela donnera au niveau des performances.
D'autres choses sont et resteront impossibles sur un noyau Linux, par exemple la possibilité d'ouvrir un fichier en connaissant uniquement son numéro d'inode (ce qui est possible dans l'API de BeOS mais un gros trou de sécurité).
La notion de window manager est plus ou moins présente. Il ne s'agit pas d'un exécutable séparé, mais plutôt d'un add-on du serveur graphique (appelé "decorator"). Cela dit, l'un ou l'autre choix est valable et n'a pas vraiment d'influence sur l'API publique.
Pour les drivers, en dehors du problème des licences, les deux gros soucis du côté de Linux sont que le code est souvent assez peu lisible (peu de commentaires, etc), et que les API internes ont tendance à beaucoup changer d'une version à l'autre. FreeBSD est, en comparaison, relativement stable, ce qui nous permet de suivre plus facilement leurs évolutions.
On regarde quand même du côté de Linux, par exemple pour les drivers graphiques. Supposément, Gallium3D permet d'avoir des drivers en userland, portables d'un OS à l'autre, mais ça n'a pas l'air d'avoir vraiment marché comme ça. On va peut-être s'inspirer de ce qu'on fait FreeBSD ou DragonFlyBSD pour récupérer les pilotes Linux.
En ce qui concerne les licences, d'une part, certains pilotes Linux sont sous licence BSD, ce qui nous va très bien (par exemple pour les cartes graphiques Intel, il me semble). D'autre part, même si un pilote est sous GPL, il peut être compilé indépendament du noyau et installé séparément, donc ce ne serait pas forcément un problème (l'avantage d'avoir une ABI propre et stable pour les pilotes de périphériques ;) ).
[^] # Re: ruche de registre ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Dark Moon : une distribution GNU/Cygwin portable pour Windows. Évalué à 9.
La version anglaise dit la même chose:
Donc ce n'est pas une traduction bizarre. La base de registre est découpée en plusieurs ruches.
Je ne connaissais pas ce terme, moi non plus.
[^] # Re: digital, vraiment ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Pollution numérique. Évalué à 6. Dernière modification le 01 août 2018 à 18:04.
Tu installes mupdf et tu pourras utiliser des commandes vim du type 42g pour aller à la page 42 ou /mot pour chercher un mot (puis n pour passer au résultat suivant). Je ne peux plus m'en passer pour naviguer dans des PDFs.
[^] # Re: Mouai...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 3.
C'est assez peu mentionné, mais les "anciens" compteurs électroniques (la génération avant Linky) permettait de récupérer ces infos directement chez soit, via un port série situé directement sur le compteur. Pourquoi il faudrait envoyer cette information au fournisseur d'énergie puis… leur demander pour y avoir accès? (accès qu'ils pourraient très bien rendre payant, d'ailleurs).
Donc le côté éducation/information, ça existait déjà, mais ça n'intéressait pas grand monde.
L'intérêt du relevé heure par heure, c'est que le fournisseur d'énergie va pouvoir facturer ça comme il veut (par exemple Direct Energie propose des heures "super creuses" à certaines périodes). On est plus limité à un modèle heures pleines/heures creuses avec des horaires fixes imposés par le distributeur d'énergie.
[^] # Re: Rions avec Microsoft
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Prononciation des options. Évalué à 3. Dernière modification le 17 juillet 2018 à 13:53.
Dans ce cas précis, on fait la liaison avec le nom de l'option, dès fois qu'il vienne l'idée de mettre une espace entre le - et l'option.
[^] # Re: et c'est dommage
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Bashing Kaspersky. Évalué à 10.
Pourquoi tu crois que ST Microelectronics est toujours vivant et présent en Europe?
Je ne suis pas certain que personne ne s'en soucie…
[^] # Site internet
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Les RMLL 2018 Strasbourg arrivent à grand pas !. Évalué à 10.
C'est rigolo 3 minutes mais pas terrible pour communiquer. J'aurais préféré un site plus classique, avec quelques images des années précédentes, ce genre de choses.
[^] # Re: Une défense des autotools
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 2.
Je dirais bien d'aller voir du côté de Jam (la version de Perforce, celle de Boost, celle de Freetype ou celle de Haiku), si c'était pas un outil non maintenu avec 3 forks incompatible… C'est dommage, parce que c'est un bon remplacement de make, avec la possibilité de définir des règles génériques, qui conviendrait pas mal pour ce genre d'usage.
[^] # Re: Une défense des autotools
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 4.
Alors je dois prendre la défense de CMake sur ce point: il y a bien une méthode standard pour la prise en charge des dossiers d'installation, c'est GNUInstallDirs. Le problème, c'est que c'est un ajout relativement récent (ça fait quelques années quand même) et que beaucoup de projets ne l'utilisent pas et codent tout en dur. Et quand c'est utilisé, ça marche tout aussi bien que les autotools (et je dis ça en ayant packagé pas mal de choses pour Haiku, qui fait des trucs bien plus tordus que slackware en terme de chemin standardisés pour les bibliothèques, les manpages, …)
Donc ce n'est pas vraiment la faute de l'outil, mais plutôt d'une mauvaise utilisation (bon et aussi du fait que les dévs de CMake ont pendant quelques temps "oublié" de documenter GNUInstallDirs…
Il y a aussi toute la gestion du packaging (avec CPack) qui de mon expérience, fonctionne plutôt bien, pour générer des tarballs. Et il y a le support de la compilation croisée.
[^] # Re: Mon expérience à deux balles
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 4.
gcc sait le faire, avec la famille d'options qui commencent par -M. Je crois qu'il peut même te générer un Makefile.
C'est ce que cmake utilise pour gérer les dépendances, par exemple.
[^] # Re: Valeur pécuniaire du logiciel libre
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 2.
La vraie raison c'est qu'il y a des distributions Linux qui vont gérer la compilation et le packaging. Donc peu de projets ont besoin de le faire d'eux-même.
[^] # Re: Le libre dans mon travail
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal France Culture: que reste-t-il du logiciel libre ?. Évalué à -3.
Non mais RMS plus personne en a grand chose à faire de ce qu'il raconte. Il y a plein d'autres organisations que la FSF qui font la promotion du libre plus efficacement et de façon pertinente. Va voir la SFC ou la FSFE par exemple.
Je vois les choses d'une façon un peu plus positive: le logiciel libre progresse plus vite que les notions d'éthique qui y étaient souvent associées. ça ne veut pas dire que la partie éthique régresse, au contraire.
[^] # Re: Cmake non ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 4.
Je précise que la communauté cmake (et son canal IRC) est pas mal réactive et disponible pour faire les modifications quand c'est nécessaire. Si tu n'es pas forcé de supporter de vieilles versions de cmake, tu pourras donc obtenir de l'aide pour régler ces problèmes, et s'il y a lieu, ce sera intégré dans cmake directement.
Je mentionne aussi au passage le très pratique cpack, qui permet de générer un .deb, un .rpm et/ou un installeur windows sans trop s'embêter. Mais peut être pas encore les .apk (ce n'est pas trop compliqué d'ajouter le support d'un nouveau format de distribution à cpack, cela dit…)
[^] # Re: Analyse très subjective!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 10.
Je plussoie complètement l'utilisation de ninja. Juste pour le plaisir de le lancer une deuxième fois quand le build est fini et de le voir dire tout de suite "nothing to do". Sur un projet comme WebKit, make dans la même situation mets chez moi presque une minute pour arriver à la même conclusion.
Autres avantages:
- Pas besoin de choisir un -j à la main comme avec make, ninja surveille le system load et s'ajuste tout seul (en tenant compte de la charge CPU effective, donc il lancera plus de jobs en parallèle si la compilation est limitée par les accès disques, et moins si elle est limitée par le CPU ou si on fait autre chose sur la machine pendant ce temps).
- Affichage correct de la sortie de la compilation, sans mélanger la sortie de différent threads
- Affichage du nombre de cibles à compiler, ce qui permet de savoir où on en est dans le build du projet
[^] # Re: Variant observée: projet dont tout les commentaires ont été supprimés
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 4.
Ma code review préférée:
[^] # Re: Mettre à dispo du code coûte cher
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à -1.
Tu peux expliquer dans ce cas, quel est l'intérêt de faire du libre si on ne veut rien gérer? J'ai un peu de mal à voir ce que ça peut apporter dans ce cas?
[^] # Re: Mettre à dispo du code coûte cher
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 1.
Certes. Tu peux faire un "lancer de code" avec une licence sur Github et on en parle plus. Mais dans ce cas il ne faut pas s'attendre à avoir automagiquement des retours positifs et plein de gens qui contribuent. Je suis d'accord, c'est quand même du libre on a rien à reprocher et c'est déjà très bien.
Mais si on veut profiter des retours de la communauté, des contributions d'autres gens, etc, il faut s'investir un peu plus que ça. ça n'est pas nécessaire, mais ça peut être une bonne justification pour faire du logiciel libre.
[^] # Re: Des exemples ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 6.
Les bugs ne sont jamais "hyper évidents". Je suis dev, je teste mon code autant que je peux mais j'ai pas un temps infini, et dans la plupart des projets il n'y a pas d'équipe QA. Donc c'est souvent moins léché qu'un truc développé correctement par une entreprise (on essaie d'améliorer ça mais c'est loin d'être facile).
Donc, contribue: plains toi que la doc est moisie, que ça plante dans tous les sens et que ça tient pas la charge. Avec des exemples précis. Y'a des chances que tu tombes sur un dev qui sera content de t'aider à régler les problèmes (c'est la contrepartie de ne pas avoir d'équipe QA ou support: tu as une ligne directe pour discuter avec les devs du projet, alors profites-en).
[^] # Re: Valeur pécuniaire du logiciel libre
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 3.
ça me rappelle les histoires avec XChat qui a voulu faire payer les binaires Windows. Sauf que c'est un logiciel libre et qu'une autre personne (silverex) fournissait déjà gratuitement les dits binaires. ça s'est mal fini et ça a forké, et maintenant tout le monde utilise hexchat à la place.
Ce modèle ne me semble pas être le plus malin. Je me dirigerais plus volontiers vers la vente de support, et éventuellement le financement du développement de nouvelles fonctionnalités. Faire payer le travail des devs plutôt que le produit fini, donc.
[^] # Re: Mettre à dispo du code coûte cher
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 2.
Si, mettre du code sous licence libre a un coût. Tu ne peux pas le nier sinon ça va jamais marcher en entreprise. Par contre, tu peux le justifier et le "vendre": expliquer les bénéfices (en termes d'image, de contributions externes, etc) et montrer que finalement, le coût initial n'est pas si important que ça en regard.
Mais si tu essaies de faire du libre sans investir sérieusement dedans, ça ne marchera pas. Et le décideur pressé va retenir ça: "le libre, ça marche pas on a essayé". Ne gâche pas ta chance et fait les choses proprement dès le début, merci :)
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 3.
ça va te coûter plus cher de maintenir ton code, qu'à quelqu'un d'autre de faire un fork et de passer un peu de temps à le nettoyer. Et en plus le fork sera 10 fois moins lourd, aura moins de bugs, etc.
Je ne vois pas comment cette recette peut être gagnante.
[^] # Re: Pas forcément commercial
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à -2.
« ce n'est pas la politique de la compagnie »
On dit pas compagnie en Français. On dit entreprise. Merci.
[^] # Re: Quelques mélanges
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 10.
On a aussi l'inverse, des gens qui disent "je publierai mon code quand il sera propre et fini". Et ça n'arrive souvent jamais.
Donc oui, merci aux gens qui publient leur code, même sale, même chiant à compiler, même pas fini, même si c'est un truc qui n'a pas servi depuis 15 ans (coucou Autodesk Animator). C'est toujours mieux que de repartir de rien.
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 7.
ça semble normal pour n'importe quel projet, hein. Si tu ne fais pas ça, un contributeur de ton projet peut venir 15 ans après et dire "hey j'ai changé d'avis, vous pouvez plus utiliser mon code". Ou si tu décides un jour de changer la licence pour les versions futures, tu dois contacter tous les contributeurs un par un pour demander s'ils sont d'accord. Ce qui est un gros bazar sur un projet comme OpenOffice, ou tu vas probablement te retrouver avec des adresses mail qui marchent plus, etc.
Donc la solution, c'est de faire signer un CLA, ou chaque contributeur dit "ok, si vous voulez changer la licence dans le futur, je dis tout de suite que je suis d'accord". ça semble être la moindre des précautions à prendre pour que la chose reste gérable.
[^] # Re: Dans un tel cas, pourquoi faire du logiciel libre ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 9.
D'autres cas:
* Le projet utilise du code GPL et est donc obligé de fournir toutes ses sources à ses clients, mais sans avoir envie que les gens se les approprient,
* Un développeur a bien envie de publier le code, mais sans avoir forcément le temps de le faire correctement,
* Un développeur a senti le vent tourner, et décide de publier les sources de son projet avant qu'il soit annulé et que tout parte à la poubelle (ça s'est produit par exemple pour Tracker, l'explorateur de fichiers de BeOS)
Parfois plus simplement, des gens ont entendu parler du logiciel libre et se disent "trop bien, on a juste à publier nos sources sur un serveur FTP et plein de gens vont venir travailler gratuitement pour nous" ou un truc de ce genre. Parfis au départ il y a quelqu'un qui a essayé de vendre le logiciel libre à son boss, mais le message n'est pas complètement passé…
De façon générale ça peut être plein de sortes de malentendus de ce genre qui aboutissent à un compromis bizarre. Sans forcément de mauvaises intentions pour autant.