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.
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.
[^] # 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.
[^] # 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.