J'utilise vim avec youcompleteme et la première chose qu'il fait avant de charger quoi que ce soit, c'est de me dire qu'il a détecté une config d'autocomplétion dans le projet et de me demander si je veux la charger. Si je dis non, la complétion intelligente et l'analyse de syntaxe sont désactivées.
Je peux également faire une liste verte des dossiers qui sont autorisés (dans laquelle je met mes projets "sûrs" pour ne pas avoir à répondre à la question chaque fois que j'ouvre un éditeur)
Ça m'est arrivé quelquefois de contribuer un peu à une dépêche pour essayer de la faire avancer, et franchement, je pense que ça n'en vaut pas la peine et qu'il vaut mieux supprimer les dépêches inactives avant que plein de gens aient commencé à passer des heures à se demander ce qu'on en fait et à essayer de compléter.
Le travail de remise à jour + les efforts pour essayer d'avoir un truc structuré et cohérent sont trop élevés, si bien que c'est plus simple de repartir de 0.
Je pense par exemple à "la voiture allergique à la glace à la vanille", créée par quelqu'un qui a juste mis un lien vers un site en anglais et demandé la permission à l'auteur de ce site de faire une traduction, et n'a pas donné suite. J'ai rédigé quelques paragraphes dedans, mais ça ne m'intéresse pas plus que ça (sous cette forme en tout cas… il y aurait des choses à dire sur comment les légendes urbaines se forment), j'aurais mieux fait de la laisser mourir.
Maintenant j'éviterai de faire des modifs de ce genre sur les dépêches inactives pour ne pas les garder en vie plus longtemps que nécessaire.
Ouais le coup de l'oomkiller c'est un peu une fausse critique. Il préfère un système qui freeze quand il n'a plus de mémoire (et donc qui te force à killer toutes les applis via un cold reboot), ou un système qui fera le ménage de lui-même dans ce cas ?
Pourquoi ça ferait un freeze?
Sous Haiku, quand il n'y a plus de mémoire, malloc() se met à retourner NULL, et les applications peuvent traiter le problème et afficher un message de type "désolé, y'a plus de mémoire, essaie de fermer une application pour faire de la place".
Et on laisse l'utilisateur (ou l'application elle-même) décider quoi fermer.
Sous Linux, avec l'OOM Killer activé, malloc ne retourne jamais NULL. Et donc les applications n'ont aucune chance de pouvoir intercepter et traiter l'erreur. Elles se font tuer directement.
Ça m'embête un peu de lire que Purism fait du open hardware. Ce n'est pas le cas pour l'instant, les schémas électriques et mécaniques ne sont pas publiés.
C'est la toute dernière étape dans leur "freedom roadmap" ici: https://puri.sm/learn/freedom-roadmap/ et ce n'est pas clair si cette roadmap concerne également les téléphones, ou seulement les PC.
Ça ne dit pas si ces schémas seront publié sous licence open hardware, d'ailleurs. Pour que ce soit du vrai open hardware, il faudrait les mettre sous une licence autorisant d'autres gens à produire le même téléphone ou des versions améliorées.
De plus cette list n'a pas été mise à jour depuis 2018.
Du côté du Pine Phone, c'est un peu mieux puisque les schémas sont disponibles (https://wiki.pine64.org/index.php/PinePhone) mais je ne vois pas d'indication de licence. Et le seul schéma électronique n'est pas suffisant pour en faire du open hardware (il faudrait les typons pour pouvoir produire les cartes électroniques, au moins).
« Le Matériel OpenSource (OSHW – OpenSource Hardware) est un terme qui regroupe des artéfacts tangibles — machines, dispositifs ou toutes choses physiques — dont les plans ont été rendus publics d’une telle façon que quiconque puisse les fabriquer, modifier, distribuer et les utiliser. Le but de cette définition est de donner des lignes directrices pour le développement et l’évaluation de licences pour du Matériel OpenSource. »
On y est pas encore, ni pour le Pine Phone ni pour les machines de chez Purism.
Et j'imagine qu'à la base le problème est un simple problème de paramétrage de la commande git. Le mec avait un git config --global user.email "<adresse@gmail.com>" et n'a pas pensé à changer la variable locale sur sa branche locale du repos git du kernel pour y mettre son email pro et son supérieur l'a remis à l'ordre.
Il ne s'agit pas d'un identifiant dans un commit, il s'agit d'une addresse de contact dans le fichier "MAINTAINERS" qui est maintenu à la main et indique qui contacter lorsqu'on veut envoyer un patch pour chaque partie du noyau Linux.
Donc ça me semble difficile de mettre la mauvaise adresse à cet endroit par erreur.
Pour le reste, les commentaires au-dessus sont corrects: a priori c'est comme ça que ça fonctionne aux USA, l'employeur peut avoir des droits y compris sur le code développé sur du temps perso. Ce n'est pas le cas en France.
Alors en fait, les numéros de ports sont associés à des noms et on peut utiliser par exemple getaddrinfo() pour faire la résolution du nom vers le numéro correspondant.
La RFC https://tools.ietf.org/html/rfc6335 explique les procédures non seulement pour demander la réservation d'un port, mais aussi la façon dont les ports peuvent être révoqués à la demande de la personne qui a fait la réservation, ou sur décision de l'IANA (c'est une nouveauté par rapport aux versions précédentes de la RFC).
Ils ont aussi calculé que au rythme actuel d'allocation des ports, on était tranquilles pour 85 ans avant de devoir ré-allouer des ports. On peut espérer que d'ici là, FTP sera bien mort et enterré?
C'est le premier lien dans le journal, la liste des ports TCP et UDP avec une recherche sur ceux qui sont "réservés". Il n'y a pas plus de détails.
Mais ça n'indique pas l'API "choix d'un port au hasard". Cependant, s'agissant d'une API, c'est plutôt du côté de la spécification POSIX que des RFC qu'il faudrait chercher.
Bah pour le coup respecté une demande faite par une minorités (3028 - 1 contre RMS vs 6261 pour RMS) c'est pas non plus tip top.
Ça serait plutôt aux Organisations qui ont signées contre RMS qui devraient remettre en question leur légitimité.
J'en prend quelques unes au hasard parmi la liste des 60 organisations signataires (pour l'instant):
GNOME
Framasoft
GNU Radio
LineageOS
Mozilla
The Tor Project
D'une part, ça fait que chacun de ces votes vaut plus de 1 personne (puisque les décideurs de chacune de ces organisations se sont mis d'accord pour signer), donc la bête comparaison par nombre de signatures, ça marche pas trop. Et d'autre part, Dire que ces gens là ne sont pas légitimes, comment dire, ça me semble un peu osé. Chacune de ces organisations prise individuellement a fait plus pour le logiciel libre ces 20 dernières années que la FSF.
Même à l'intérieur de la FSF et du projet GNU le board de la FSF est lâché par pas mal de monde. Par exemple le projet gcc envisage sérieusement de quitter la FSF et le projet GNU et d'être hébergé ailleurs.
Si j'ai bien suivi, le principe est de trier plein d'histoires de "pourquoi rien ne marche en informatique et pourquoi ça sera toujours compliqué" et de les trier par ordre des plus connues aux plus obscures.
Il y a des liens pour chacune d'entre elles, donc si y'a quelque chose qui vous dit rien, c'est l'occasion de cliquer dessus et de devenir un peu plus désespéré sur le fait que toute l'informatique (et par conséquent probablement une grosse partie de la civilisation humaine) tient debout grace à des bouts de scotchs et des ficelles.
Je te rejoins par rapport à tout ceci. Le client Signal est libre, mais pas toutes l'infrastructure derrière, puisque cela repose sur un service centralisé. Il me semble que le client Telegram (officiel) est libre, en tout cas ils contribuent, j'ai l'impression, autant au libre que Signal
Pour Signal, le code du serveur est également libre (sous license AGPL). Pour Telegram, ce n'est pas le cas.
Ça fait quand même une différence (importante ou pas, à chacun d'en décider).
J'en pense que je vais continuer à utiliser XMPP, un système décentralisé avec plein d'acteurs, comme ça si un développeur de lcient ou de serveur ou un hébergeur de serveur fait n'importe quoi, je peux juste changer de crèmerie tout en continuant à discuter avec mes contacts.
Je ne pense pas que les solutions de type "libre mais centralisé" soient très intéressantes par rapport aux solutions non libres.
L’objectif théorique de la revue de code est de permettre à un développeur de s’améliorer grâce à la critique constructive de ses collègues.
Alors déjà ça, c'est prendre de haut les gens dont on relit le code. Forcément avec une attitude pareille, ça risque de pas marcher.
Pour moi, en particulier (mais pas seulement) dans un projet open source, l'objectif de la revue de code, c'est plutôt, en tant que relecteur, de s'assurer qu'on comprend bien le code qu'on va merger et devoir ensuite maintenir.
Dans mes projets pro, c'est fréquent que les nouveaux arrivants commencent par faire de la revue de code dans leurs premières tâches. Ça leur permet de poser plein de questions sur l'architecture du projet et donc de comprendre comment ça marche. Beaucoup plus efficacement qu'en écrivant du code puis en se faisant "démolir" (c'est le mot utilisé dans l'article) quand il est relu.
Il a le droit de dire ce qu'il veut. La question, c'est est-ce que la FSF fait bien de garder dans son board quelqu'un qui tient ce genre de propos. Note la différence entre se faire virer du bureau d'une association, et se faire envoyer en prison ou devoir payer une amende.
Ces exemples sont bel et bien un symptôme de son manque d'empathie.
Mais en fait c'est bien ça le problème. Il est très centré sur le logiciel libre et il se fout de tout le reste: le open hardware, le creative commons pour l'art, l'accessibilité…
Pourtant des sujets qui méritent qu'on s'y intéresse un peu quand on parle de logiciel libre. Il y a matière à collaborer, des idées à partager ou à reprendre, …
Et le deuxième problème c'est que la FSF est à son image. Elle aussi mériterait plus d'ouverture et de s'intéresser à d'autres sujets. Ce qui serait plus simple à faire si à la tête de la FSF il y avait pas tout le temps la même personne depuis 30 ans.
Moi je me rapelle d'un organisateur des RMLL (je sais plus en quelle année) qui m'avait plutôt expliqué que ça l'ennuyait beaucoup de devoir inviter Stallman, d'une part à cause de son comportement pas très agréable et de son discours extrêmiste sur le logiciel libre (qui est forcément clivant), et d'autre part parce qu'il faut gérer toute la logistique pour le recevoir (refus de prendre des transports ou un hébergement ou il faut donner une pièce d'identité, etc).
Mais par contre, c'est une personnalité reconnue, et quand on organise un truc en disant "on va invoter Stallman", ça marche vachement bien pour obtenir des subventions et le soutien d'autres gens (hors du logiciel libre, donc) pour organiser les choses.
[^] # Re: Pas de solution ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Exfiltration de données via des macros Rust. Évalué à 2.
J'utilise vim avec youcompleteme et la première chose qu'il fait avant de charger quoi que ce soit, c'est de me dire qu'il a détecté une config d'autocomplétion dans le projet et de me demander si je veux la charger. Si je dis non, la complétion intelligente et l'analyse de syntaxe sont désactivées.
Je peux également faire une liste verte des dossiers qui sont autorisés (dans laquelle je met mes projets "sûrs" pour ne pas avoir à répondre à la question chaque fois que j'ouvre un éditeur)
[^] # Re: Six mois plus tard
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à l’entrée du suivi Réduire la liste de dépêche en cours de rédactions. Évalué à 3 (+0/-0).
Ça m'est arrivé quelquefois de contribuer un peu à une dépêche pour essayer de la faire avancer, et franchement, je pense que ça n'en vaut pas la peine et qu'il vaut mieux supprimer les dépêches inactives avant que plein de gens aient commencé à passer des heures à se demander ce qu'on en fait et à essayer de compléter.
Le travail de remise à jour + les efforts pour essayer d'avoir un truc structuré et cohérent sont trop élevés, si bien que c'est plus simple de repartir de 0.
Je pense par exemple à "la voiture allergique à la glace à la vanille", créée par quelqu'un qui a juste mis un lien vers un site en anglais et demandé la permission à l'auteur de ce site de faire une traduction, et n'a pas donné suite. J'ai rédigé quelques paragraphes dedans, mais ça ne m'intéresse pas plus que ça (sous cette forme en tout cas… il y aurait des choses à dire sur comment les légendes urbaines se forment), j'aurais mieux fait de la laisser mourir.
Maintenant j'éviterai de faire des modifs de ce genre sur les dépêches inactives pour ne pas les garder en vie plus longtemps que nécessaire.
[^] # Re: C'est pas un peu la mode du moment ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le désenchantement du logiciel. Évalué à 4.
La solution à "y'a trop de code" serait donc d'ajouter du code pour empêcher le code de s'exécuter… intéressant comme approche…
[^] # Re: Encore un qui n’utilise pas assez GNU/Linux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le désenchantement du logiciel. Évalué à 4.
Pourquoi ça ferait un freeze?
Sous Haiku, quand il n'y a plus de mémoire, malloc() se met à retourner NULL, et les applications peuvent traiter le problème et afficher un message de type "désolé, y'a plus de mémoire, essaie de fermer une application pour faire de la place".
Et on laisse l'utilisateur (ou l'application elle-même) décider quoi fermer.
Sous Linux, avec l'OOM Killer activé, malloc ne retourne jamais NULL. Et donc les applications n'ont aucune chance de pouvoir intercepter et traiter l'erreur. Elles se font tuer directement.
[^] # Re: Purism et le open hardware
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Quel téléphone (plus ou moins) libre en 2021 ?. Évalué à 2.
En effet. Il n'y a que les schémas et pas les typons (il faudrait donc refaire le routage des cartes électroniques), mais c'est déjà pas mal.
Il n'y a pas de license indiquée dans le pdf du schéma, est-ce que la license cc-by-sa de la page s'applique aussi au pdf lié, ou pas?
# Purism et le open hardware
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Quel téléphone (plus ou moins) libre en 2021 ?. Évalué à 10.
Ça m'embête un peu de lire que Purism fait du open hardware. Ce n'est pas le cas pour l'instant, les schémas électriques et mécaniques ne sont pas publiés.
C'est la toute dernière étape dans leur "freedom roadmap" ici: https://puri.sm/learn/freedom-roadmap/ et ce n'est pas clair si cette roadmap concerne également les téléphones, ou seulement les PC.
Ça ne dit pas si ces schémas seront publié sous licence open hardware, d'ailleurs. Pour que ce soit du vrai open hardware, il faudrait les mettre sous une licence autorisant d'autres gens à produire le même téléphone ou des versions améliorées.
De plus cette list n'a pas été mise à jour depuis 2018.
Du côté du Pine Phone, c'est un peu mieux puisque les schémas sont disponibles (https://wiki.pine64.org/index.php/PinePhone) mais je ne vois pas d'indication de licence. Et le seul schéma électronique n'est pas suffisant pour en faire du open hardware (il faudrait les typons pour pouvoir produire les cartes électroniques, au moins).
Je prend cette définition sur Wikipedia (https://fr.wikipedia.org/wiki/Mat%C3%A9riel_libre):
On y est pas encore, ni pour le Pine Phone ni pour les machines de chez Purism.
[^] # Re: comment ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien You are an IBM employee 100% of the time.. Évalué à 4. Dernière modification le 22 avril 2021 à 19:05.
Il ne s'agit pas d'un identifiant dans un commit, il s'agit d'une addresse de contact dans le fichier "MAINTAINERS" qui est maintenu à la main et indique qui contacter lorsqu'on veut envoyer un patch pour chaque partie du noyau Linux.
Donc ça me semble difficile de mettre la mauvaise adresse à cet endroit par erreur.
Pour le reste, les commentaires au-dessus sont corrects: a priori c'est comme ça que ça fonctionne aux USA, l'employeur peut avoir des droits y compris sur le code développé sur du temps perso. Ce n'est pas le cas en France.
[^] # Re: E-mail
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien ./play.it — DMCA Copyright Infringement Notification. Évalué à 10.
Pendant 20 ans les moules se sont plaint des journaux bookmark, tout ça pour en arriver là…
[^] # Re: Gruik
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L'étrange affaire du port 0. Évalué à 5.
Alors en fait, les numéros de ports sont associés à des noms et on peut utiliser par exemple getaddrinfo() pour faire la résolution du nom vers le numéro correspondant.
[^] # Re: Port 22
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L'étrange affaire du port 0. Évalué à 7.
La RFC https://tools.ietf.org/html/rfc6335 explique les procédures non seulement pour demander la réservation d'un port, mais aussi la façon dont les ports peuvent être révoqués à la demande de la personne qui a fait la réservation, ou sur décision de l'IANA (c'est une nouveauté par rapport aux versions précédentes de la RFC).
Ils ont aussi calculé que au rythme actuel d'allocation des ports, on était tranquilles pour 85 ans avant de devoir ré-allouer des ports. On peut espérer que d'ici là, FTP sera bien mort et enterré?
[^] # Re: Noyau Linux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L'étrange affaire du port 0. Évalué à 5. Dernière modification le 18 avril 2021 à 17:15.
C'est le premier lien dans le journal, la liste des ports TCP et UDP avec une recherche sur ceux qui sont "réservés". Il n'y a pas plus de détails.
Mais ça n'indique pas l'API "choix d'un port au hasard". Cependant, s'agissant d'une API, c'est plutôt du côté de la spécification POSIX que des RFC qu'il faudrait chercher.
[^] # Re: Parallèle avec la politique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal GNU t'es la ?. Évalué à 10.
GNOME n'est pas un projet lié à GNU ou à la FSF.
Le seul environnement graphique disponible dans GNU, c'est emacs.
[^] # Re: Pas gagné, on verra le long terme...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Stallman va rester a la FSF. Évalué à 1.
J'ai pas dit qu'ils étaient parfaits, juste qu'ils ont fait mieux que la fsf. Et oui, c'est très facile de faire mieux que la fsf.
[^] # Re: Pas gagné, on verra le long terme...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Stallman va rester a la FSF. Évalué à 6.
J'en prend quelques unes au hasard parmi la liste des 60 organisations signataires (pour l'instant):
D'une part, ça fait que chacun de ces votes vaut plus de 1 personne (puisque les décideurs de chacune de ces organisations se sont mis d'accord pour signer), donc la bête comparaison par nombre de signatures, ça marche pas trop. Et d'autre part, Dire que ces gens là ne sont pas légitimes, comment dire, ça me semble un peu osé. Chacune de ces organisations prise individuellement a fait plus pour le logiciel libre ces 20 dernières années que la FSF.
Même à l'intérieur de la FSF et du projet GNU le board de la FSF est lâché par pas mal de monde. Par exemple le projet gcc envisage sérieusement de quitter la FSF et le projet GNU et d'être hébergé ailleurs.
[^] # Re: Excellent
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien The Cursed Computer Iceberg Meme. Évalué à 3.
Si j'ai bien suivi, le principe est de trier plein d'histoires de "pourquoi rien ne marche en informatique et pourquoi ça sera toujours compliqué" et de les trier par ordre des plus connues aux plus obscures.
Il y a des liens pour chacune d'entre elles, donc si y'a quelque chose qui vous dit rien, c'est l'occasion de cliquer dessus et de devenir un peu plus désespéré sur le fait que toute l'informatique (et par conséquent probablement une grosse partie de la civilisation humaine) tient debout grace à des bouts de scotchs et des ficelles.
[^] # Re: XMPP
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Signal envoie des signaux inquiétants. Évalué à 6.
Pour Signal, le code du serveur est également libre (sous license AGPL). Pour Telegram, ce n'est pas le cas.
Ça fait quand même une différence (importante ou pas, à chacun d'en décider).
# XMPP
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Signal envoie des signaux inquiétants. Évalué à 10.
J'en pense que je vais continuer à utiliser XMPP, un système décentralisé avec plein d'acteurs, comme ça si un développeur de lcient ou de serveur ou un hébergeur de serveur fait n'importe quoi, je peux juste changer de crèmerie tout en continuant à discuter avec mes contacts.
Je ne pense pas que les solutions de type "libre mais centralisé" soient très intéressantes par rapport aux solutions non libres.
[^] # Re: Oh punaise
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche La version 0.32.0 de Xcpc est disponible. Évalué à 3.
…et moi je devrais faire un journal sur le portage de ACE de MorphOS vers Haiku (note: projet non libre).
Si ça continue on va avoir plus d'émulateurs que d'utidisateurs potentiels :o)
[^] # Re: Une triste page de LinuxFR qui se tourne
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Bannissement d'un utilisateur et évolution de la modération. Évalué à 10. Dernière modification le 07 avril 2021 à 17:14.
En fait c'est une bête histoire de rapport signal/bruit?
# L'objectif de la revue de code
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Mais la revue de code, ça sert à rien ?. Évalué à 10.
Alors déjà ça, c'est prendre de haut les gens dont on relit le code. Forcément avec une attitude pareille, ça risque de pas marcher.
Pour moi, en particulier (mais pas seulement) dans un projet open source, l'objectif de la revue de code, c'est plutôt, en tant que relecteur, de s'assurer qu'on comprend bien le code qu'on va merger et devoir ensuite maintenir.
Dans mes projets pro, c'est fréquent que les nouveaux arrivants commencent par faire de la revue de code dans leurs premières tâches. Ça leur permet de poser plein de questions sur l'architecture du projet et donc de comprendre comment ça marche. Beaucoup plus efficacement qu'en écrivant du code puis en se faisant "démolir" (c'est le mot utilisé dans l'article) quand il est relu.
[^] # Re: Contre lettre
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal RMS et la FSF. Évalué à 6.
Il a le droit de dire ce qu'il veut. La question, c'est est-ce que la FSF fait bien de garder dans son board quelqu'un qui tient ce genre de propos. Note la différence entre se faire virer du bureau d'une association, et se faire envoyer en prison ou devoir payer une amende.
[^] # Re: résumé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal La pétition anti Stallman, anti FSF, anti GPL. Évalué à 4.
Mais en fait c'est bien ça le problème. Il est très centré sur le logiciel libre et il se fout de tout le reste: le open hardware, le creative commons pour l'art, l'accessibilité…
Pourtant des sujets qui méritent qu'on s'y intéresse un peu quand on parle de logiciel libre. Il y a matière à collaborer, des idées à partager ou à reprendre, …
Et le deuxième problème c'est que la FSF est à son image. Elle aussi mériterait plus d'ouverture et de s'intéresser à d'autres sujets. Ce qui serait plus simple à faire si à la tête de la FSF il y avait pas tout le temps la même personne depuis 30 ans.
[^] # Re: résumé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal La pétition anti Stallman, anti FSF, anti GPL. Évalué à 4.
Moi je me rapelle d'un organisateur des RMLL (je sais plus en quelle année) qui m'avait plutôt expliqué que ça l'ennuyait beaucoup de devoir inviter Stallman, d'une part à cause de son comportement pas très agréable et de son discours extrêmiste sur le logiciel libre (qui est forcément clivant), et d'autre part parce qu'il faut gérer toute la logistique pour le recevoir (refus de prendre des transports ou un hébergement ou il faut donner une pièce d'identité, etc).
Mais par contre, c'est une personnalité reconnue, et quand on organise un truc en disant "on va invoter Stallman", ça marche vachement bien pour obtenir des subventions et le soutien d'autres gens (hors du logiciel libre, donc) pour organiser les choses.
C'était donc plutôt un mal nécessaire.
[^] # Re: Memory leak et warnings
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 723, +5736, -5696… un mois de travail de résurrection d'un projet libre…. Évalué à 4.
C'est dans la doc de gcc: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Voir l'option -Werror= (avec le = suivi du nom du warning)
[^] # Re: Ça pue c'est pas libre.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal RMS et la FSF. Évalué à 2.
Bonjour,
On fait du logiciel libre en utilisant les outils qu'on veut.