Organisation souple du télétravail : chacun s'organise avec ses collègues pour être en télétravail d'une semaine à l'autre. Une partie de l'équipe en télétravail complet avec regroupements chaque trimestre (2 obligatoires par an). En pratique les "locaux" sont soit en full présentiel, soit 1 ou 2J par semaine au bureau.
Perso je suis exceptionnellement en télétravail : même pour travailler isolé je préfère être au bureau.
Le principal gros frein au télétravail fluide à mon sens est le manque de culture de l'écrit. Souvent le management est critiqué mais en même temps la communication écrite n'est souvent pas naturelle pour les salariés et les réunions et visions sont considérées comme inutiles (ça transparaît un peu dans les commentaires ici, ça se voit à mort sur les réseaux sociaux).
Le second gros frein est le transfert de compétences et la formation des plus jeunes. Ça reste plus compliqué/coûteux/laborieux qu'en présentiel. D'ailleurs des écoles comme 42 semblent désormais refuser les stages en télétravail.
Je l'ai fait au démarrage d'Algoo. Ça m'a rassuré sur le fait de passer le pas. 10 mois plus tard, j'avais un peu de trésorerie (en partie lié à cette aide) et ça m'a permis d'embauche le premier salarié. 5 mois plus tard j'embauchais le second …
Du coup je comprends ce que tu dis, et en même temps je pense que sans ça, je n'aurais pas embauché car peu de visiblité …
Déjà tu peux contacter les mainteneurs officiels, leur expliquer ton besoin et leur dire que tu peux contribuer financièrement au développement. Ce devrait être de loin le meilleur rapport qualité/prix vu qu'ils devraient torcher ça plus rapidement que n'importe qui.
Je pense que c'est la meilleure option, et en tout cas l'option à creuser en priorité.
Si ils déclinent, tu peux aller farfouiller dans le code, regarder les contributions extérieures (surtout pour des contributions que tu penses proches de ton besoin) et tu fais de même. Idem, tu vas toucher des gens compétents sur ce besoin précis, ce qui ne sera pas forcément le cas via des plateformes (où tu toucheras des développeurs, sûrement bons, mais qui devront passer pas mal de temps à entrer dans le problème).
Si tu ne trouves pas de profil spécialisé je t'invite à nous solliciter à Algoo. On n'est pas spécialistes de libvirt mais on fait du dév sur mesure et on a un développeur qui sera compétent et emballé d'intervenir sur ce genre de code.
On connait aussi bien l'écosystème logiciel libre donc on pourra interagir en respectant les codes et (bonnes) pratiques.
J'ai découvert récemment en discutant avec un prospect galae qu'ils ont même un webmail … historiquement ils étaient connus pour l'aspect commercial (CRM / plateforme suivi client), mais aujourd'hui ils ont élargi leur positionnement :
slogan : Notre travail au service du vôtre. Une suite logicielle unique et puissante pour transformer votre façon de travailler. Conçue pour les entreprises de toutes tailles et créée par une entreprise engagée dans la protection de votre confidentialité.
Dans l'ordre ils présentent sur leur site web :
CRM
Messagerie
Desk (service client)
Creator (applications sur mesure ?)
Assist (assistance et prise en main à distance - support client quoi)
et tu en déduis "pas d'école d'ingé => pas capable de détecter le bullshit"
Ce que tu écrits c'est : 100% des ingénieurs sortant d'écoles prestigieuses sont capables de détecter le bullshit.
Étant donné que tout le monde n'est pas capable (une partie de la population se fait avoir par le bullshit), on a donc x % de la population est capable de détecter le bullshit, avec x < 100.
Cela signifie donc que pourcentage ingénieurs capable de détecter le bullshit > pourcentage de la population capable de détecter le bullshit.
J'ai fait une école d'ingénieur. J'en ai même fait 2 :-p J'ai croisé beaucoup de gens intelligents voire très intelligents. Parmi toutes ces personnes une part manquait d'esprit critique, de pragmatisme, de bon sens … Ça dépend. Il n'y a pas de règle.
Avec tous les biais que ça peut avoir, on peut au moins préjugés que quand on sort d'une école d'ingé prestigieuse, on sait ce qui est du bullshit de ce qui ne l'est pas.
Je suis dubitatif sur le sous entendu : on serait en moyenne moins capable de détecter le bullshit si on ne sort pas des écoles d'ingénieurs prestigieuses.
Pour ne pas se faire avoir par ce type de discours, c'est plutôt du bon sens, une démarche d'analyse et de l'esprit critique qu'il faut avoir ; ça n'est pas enseigné à ma connaissance … Ni en école d'ingénieur, ni ailleurs.
Est-ce que c'est utile de consacrer deux années à apprendre les tables de multiplication alors qu'il est hautement improbable de se situer à moins de 50cm d'une calculatrice dans les 70 ans qui viennent? Est-ce que c'est utile d'apprendre à maitriser l'ortho[…]
En apprenant les bases, tu apprends à apprendre. Si tu apprends à utiliser une calculatrice, c'est bien, mais tu ne sais pas calculer.
Dans un domaine très proche de celui qui nous concerne ici en majorité, tu vois rapidement la différence entre les développeurs qui savent faire des ORM, des développeurs qui savent faire du SQL et les développeurs qui savent comment fonctionnent les moteurs de base de données.
Apprendre à compter, à écrire, à comprendre comment ça fonctionne à la base, avec les règles fondamentales, c'est supprimer le plafond de verre qui t'attend inévitablement si tu te contentes d'apprendre les outils.
Si l'école publique ne t'apprend pas ça, qui va le faire ? Et à qui cela sera-t-il accessible ?
J'ai vu peu de personnes s'en servir (en fait même, personne)
Tu le dis toi-même.
Plus largement, je pense que l'édition locale (réseau local) à plusieurs est un sous-ensemble de l'édition collaborative en ligne - ce que libreoffice sait faire
la licence s'applique à la distribution : s'il y a de la GPL en amont,
la résultante sera en GPL pour du compilé en statique (puisque ça inclus de la GPL)
la résultante ne sera pas forcément en GPL pour du compilé en dynamique
pour du code interprété, ça dépend…
Moi justement je suis dans le cas du code interprété… On fait du python et du javascript.
Python est compilé en bytecode mais on fournit les sources et la compilation est faite au démarrage (mais si je ne me trompes pas on pourrait distribuer uniquement les pyc, ça marcherait aussi).
La partie frontend est en JS transpilé et minifié … Je ne sais pas si ça rentre dans le cadre de ce qu'on appelle "compilation".
Par contre ce que j'en comprends aussi c'est que si c'est du webassembly, ça s'applique (et c'est assez naturel).
Imaginons que plus personne ne fasse de logiciel propriétaire. Ton modèle économique est mort.
C'est différent pour celui de Zenitram.
Dans l'exemple de ta blague - que je trouve hyper représentatif du sujet, plus les gens sont malpolis, plus tu gagnes d'argent. On ne peut pas dire que ça soit vertueux pour la politesse car tu n'as strictement aucune raison de les inciter à parler poliment.
C'est d'autant plus vrai que ton modèle tombe à 0€ de CA si on fait du libre.
Au doigt mouillé, j'ai le sentiment qu'aujourd'hui les deux modèles dominants, c'est l'open core et la vente de services/formations.
Au niveau des éditeurs le modèle le plus largement étendu est l'opencore. Les cas comme Nextcloud, XWiki, Tracim, etc sont clairement pas la majorité.
Tout ce qui est vraiment libre (GPL) génère beaucoup d'économie de type service, mais la majorité du temps, il ne s'agit pas de contribuer en R&D et sans un éditeur solide derrière la solution, c'est compliqué. Combien de boîtes gagnent leur vie sans dépenser le moindre centime chez Nextcloud, gitlab, mattermost, etc ? L'éditeur a intérêt à avoir un modèle solide, pas pour sa propre survie (c'est une évidence) mais pour que toutes ces boîtes puissent continuer à assurer leur service.
MIT rassure les entreprises privées car avec la GPL elles ont peur de la contagion. A savoir qu'elles ont peur de devoir mettre tous leur soft en GPL s'il y a un bout de GPL dedans. C'est faux mais le lobby anti-open-source joue dessus et les PME n'ont pas les moyens d'étudier plus la question.
?
Dit autrement : si on veut produire du code qu'on ne souhaite pas diffuser sous GPL, on ne peut pas s'appuyer sur des dépendances publiées en GPL ?
Je pose la question sérieusement, je pense ne pas être nase en licence mais j'attends mes limites, surtout s'il y a des distinctions à faire entre code source et version compilée …
C'est faux mais le lobby anti-open-source joue dessus et les PME n'ont pas les moyens d'étudier plus la question.
Je veux bien que tu m'éduques. Qu'est-ce qui est faux ? Si tu mets du GPL, tout ce qui dérive (ou dépend exclusivement) doit être GPL. En tout cas c'est ce que je comprends.
Je suis preneur de ton explication ainsi que la raison pour laquelle la LGPL a été créée.
Je ne dis pas le contraire. J'ai publié un post de blog sur le site algoo sur le sujet : dès qu'il y a des levées de fond, le ROI devient d'une manière ou d'une autre l'objectif en ligne de mire.
Ce que je dis (ou que j'essaie de dire) :
Facebook, Google aussi ont des investisseurs et le ROI en ligne de mire. Mais dans le cas des technologies qu'ils développent, il s'agit d'outils, pas de leur "machine à cash". D'ailleurs ils ne vendent pas de service autour de leurs briques techno, je pense.
Dans ce contexte il est beaucoup plus facile pour eux de ne pas fermer le code car il n'y a pas d'enjeu fort de ROI sur le développement des produits. Et c'est d'autant plus efficace pour assurer la pérennité du projet. Il n'y a pas de concurrence commerciale dans ce cas de figure.
Par ailleurs, merci pour l'historique des boîtes autour de Redis, je ne connaissais pas 👌
C'est possible si tu arrives à contacter l'intégralité des contributeurs. En pratique dès que ton projet dure un peu c'est compliqué (ou alors il faut réécrire des trucs, ce qui peut être compliqué selon les cas)…
En fait dans les exemples que tu présentes, il me semble que seul Redis est le coeur de métier de son éditeur, son gagne-pain.
Le problème c'est quand un éditeur gagne sa vie avec son produit et que des concurrents viennent le concurrencer. Kubernetes, Cassandra etc il me semble que le business des éditeurs de ces solutions ne repose pas sur la monétisation des outils qu'ils ont développé.
J'avais vu cette page mais je n'avais pas compris les choses comme ça. Mais effectivement, avec ta lecture ça me semble logique et je comprends la même chose maintenant.
C'est le risque en publiant sur linuxfr, et c'est aussi l'avantage de cet espace : les échanges peuvent digresser et c'est ce qui en fait tout l'intérêt. (raphj n'aurait peut-être pas partagé son script sans mon journal, et manifestement ça intéresse donc c'est très bien comme ça)
# Dirigeant
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Télétravailleurs, distanciels : quel métier faites vous ?. Évalué à 4 (+2/-0).
Organisation souple du télétravail : chacun s'organise avec ses collègues pour être en télétravail d'une semaine à l'autre. Une partie de l'équipe en télétravail complet avec regroupements chaque trimestre (2 obligatoires par an). En pratique les "locaux" sont soit en full présentiel, soit 1 ou 2J par semaine au bureau.
Perso je suis exceptionnellement en télétravail : même pour travailler isolé je préfère être au bureau.
Le principal gros frein au télétravail fluide à mon sens est le manque de culture de l'écrit. Souvent le management est critiqué mais en même temps la communication écrite n'est souvent pas naturelle pour les salariés et les réunions et visions sont considérées comme inutiles (ça transparaît un peu dans les commentaires ici, ça se voit à mort sur les réseaux sociaux).
Le second gros frein est le transfert de compétences et la formation des plus jeunes. Ça reste plus compliqué/coûteux/laborieux qu'en présentiel. D'ailleurs des écoles comme 42 semblent désormais refuser les stages en télétravail.
[^] # Re: Et pendant ce temps
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Chomeur et bénévole ? Achtung. Évalué à 2 (+0/-0).
Oui je comprends la diff …
[^] # Re: Et pendant ce temps
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Chomeur et bénévole ? Achtung. Évalué à 3 (+1/-0).
Je l'ai fait au démarrage d'Algoo. Ça m'a rassuré sur le fait de passer le pas. 10 mois plus tard, j'avais un peu de trésorerie (en partie lié à cette aide) et ça m'a permis d'embauche le premier salarié. 5 mois plus tard j'embauchais le second …
Du coup je comprends ce que tu dis, et en même temps je pense que sans ça, je n'aurais pas embauché car peu de visiblité …
Du coup j'ai un avis plus mitigé.
[^] # Re: Et pendant ce temps
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Chomeur et bénévole ? Achtung. Évalué à 2 (+0/-0).
Tu parles de l'Aide à la reprise ou à la création d'entreprise (Arce) ?
[^] # Re: Plusieurs pistes
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Plateforme d'échange rémunéré de service de développement. Évalué à 10 (+9/-0). Dernière modification le 02 mai 2024 à 12:13.
Je pense que c'est la meilleure option, et en tout cas l'option à creuser en priorité.
Si tu ne trouves pas de profil spécialisé je t'invite à nous solliciter à Algoo. On n'est pas spécialistes de libvirt mais on fait du dév sur mesure et on a un développeur qui sera compétent et emballé d'intervenir sur ce genre de code.
On connait aussi bien l'écosystème logiciel libre donc on pourra interagir en respectant les codes et (bonnes) pratiques.
[^] # Re: Zoho ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Des entreprises africaines préfèrent Zoho à Google et Microsoft. Évalué à 2 (+0/-0).
J'ai découvert récemment en discutant avec un prospect galae qu'ils ont même un webmail … historiquement ils étaient connus pour l'aspect commercial (CRM / plateforme suivi client), mais aujourd'hui ils ont élargi leur positionnement :
Dans l'ordre ils présentent sur leur site web :
[^] # Re: Une explication possible…
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Le marketing des logiciels, épisode 20240410. Évalué à 5 (+3/-0).
Ce que tu écrits c'est : 100% des ingénieurs sortant d'écoles prestigieuses sont capables de détecter le bullshit.
Étant donné que tout le monde n'est pas capable (une partie de la population se fait avoir par le bullshit), on a donc
x % de la population est capable de détecter le bullshit, avecx < 100.Cela signifie donc que
pourcentage ingénieurs capable de détecter le bullshit > pourcentage de la population capable de détecter le bullshit.J'ai fait une école d'ingénieur. J'en ai même fait 2 :-p J'ai croisé beaucoup de gens intelligents voire très intelligents. Parmi toutes ces personnes une part manquait d'esprit critique, de pragmatisme, de bon sens … Ça dépend. Il n'y a pas de règle.
[^] # Re: Une explication possible…
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Le marketing des logiciels, épisode 20240410. Évalué à 7 (+5/-0).
Je suis dubitatif sur le sous entendu : on serait en moyenne moins capable de détecter le bullshit si on ne sort pas des écoles d'ingénieurs prestigieuses.
Pour ne pas se faire avoir par ce type de discours, c'est plutôt du bon sens, une démarche d'analyse et de l'esprit critique qu'il faut avoir ; ça n'est pas enseigné à ma connaissance … Ni en école d'ingénieur, ni ailleurs.
[^] # Re: Réactionnaire
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien « Impact catastrophique » : le gouvernement explore le bannissement des smartphones des collèges . Évalué à 9 (+7/-0).
En apprenant les bases, tu apprends à apprendre. Si tu apprends à utiliser une calculatrice, c'est bien, mais tu ne sais pas calculer.
Dans un domaine très proche de celui qui nous concerne ici en majorité, tu vois rapidement la différence entre les développeurs qui savent faire des ORM, des développeurs qui savent faire du SQL et les développeurs qui savent comment fonctionnent les moteurs de base de données.
Apprendre à compter, à écrire, à comprendre comment ça fonctionne à la base, avec les règles fondamentales, c'est supprimer le plafond de verre qui t'attend inévitablement si tu te contentes d'apprendre les outils.
Si l'école publique ne t'apprend pas ça, qui va le faire ? Et à qui cela sera-t-il accessible ?
# parce que ça n'intéresse pas les utilisateurs ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message libreoffice : onglets et édition de documents en réseau?. Évalué à 3 (+1/-0).
Tu le dis toi-même.
Plus largement, je pense que l'édition locale (réseau local) à plusieurs est un sous-ensemble de l'édition collaborative en ligne - ce que libreoffice sait faire
[^] # Re: pros / cons
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 2 (+0/-0).
Moi justement je suis dans le cas du code interprété… On fait du python et du javascript.
Python est compilé en bytecode mais on fournit les sources et la compilation est faite au démarrage (mais si je ne me trompes pas on pourrait distribuer uniquement les pyc, ça marcherait aussi).
La partie frontend est en JS transpilé et minifié … Je ne sais pas si ça rentre dans le cadre de ce qu'on appelle "compilation".
Par contre ce que j'en comprends aussi c'est que si c'est du webassembly, ça s'applique (et c'est assez naturel).
Merci pour les explications en tout cas 👌
[^] # Re: L'auteur ou les auteurs ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 4 (+2/-0).
Imaginons que plus personne ne fasse de logiciel propriétaire. Ton modèle économique est mort.
C'est différent pour celui de Zenitram.
Dans l'exemple de ta blague - que je trouve hyper représentatif du sujet, plus les gens sont malpolis, plus tu gagnes d'argent. On ne peut pas dire que ça soit vertueux pour la politesse car tu n'as strictement aucune raison de les inciter à parler poliment.
C'est d'autant plus vrai que ton modèle tombe à 0€ de CA si on fait du libre.
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 3 (+1/-0).
Au niveau des éditeurs le modèle le plus largement étendu est l'opencore. Les cas comme Nextcloud, XWiki, Tracim, etc sont clairement pas la majorité.
Tout ce qui est vraiment libre (GPL) génère beaucoup d'économie de type service, mais la majorité du temps, il ne s'agit pas de contribuer en R&D et sans un éditeur solide derrière la solution, c'est compliqué. Combien de boîtes gagnent leur vie sans dépenser le moindre centime chez Nextcloud, gitlab, mattermost, etc ? L'éditeur a intérêt à avoir un modèle solide, pas pour sa propre survie (c'est une évidence) mais pour que toutes ces boîtes puissent continuer à assurer leur service.
[^] # Re: pros / cons
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 3 (+1/-0).
Du coup on est d'accord que ceci est faux :
?
Dit autrement : si on veut produire du code qu'on ne souhaite pas diffuser sous GPL, on ne peut pas s'appuyer sur des dépendances publiées en GPL ?
Je pose la question sérieusement, je pense ne pas être nase en licence mais j'attends mes limites, surtout s'il y a des distinctions à faire entre code source et version compilée …
[^] # Re: pros / cons
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 3 (+1/-0).
Je veux bien que tu m'éduques. Qu'est-ce qui est faux ? Si tu mets du GPL, tout ce qui dérive (ou dépend exclusivement) doit être GPL. En tout cas c'est ce que je comprends.
Je suis preneur de ton explication ainsi que la raison pour laquelle la LGPL a été créée.
[^] # Re: Ah si ils l'aiment l'open source...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Redis Open Source bronsonisé. Évalué à 2 (+0/-0).
Je ne dis pas le contraire. J'ai publié un post de blog sur le site algoo sur le sujet : dès qu'il y a des levées de fond, le ROI devient d'une manière ou d'une autre l'objectif en ligne de mire.
Ce que je dis (ou que j'essaie de dire) :
Facebook, Google aussi ont des investisseurs et le ROI en ligne de mire. Mais dans le cas des technologies qu'ils développent, il s'agit d'outils, pas de leur "machine à cash". D'ailleurs ils ne vendent pas de service autour de leurs briques techno, je pense.
Dans ce contexte il est beaucoup plus facile pour eux de ne pas fermer le code car il n'y a pas d'enjeu fort de ROI sur le développement des produits. Et c'est d'autant plus efficace pour assurer la pérennité du projet. Il n'y a pas de concurrence commerciale dans ce cas de figure.
Par ailleurs, merci pour l'historique des boîtes autour de Redis, je ne connaissais pas 👌
[^] # Re: Quelques exemples
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 5 (+3/-0).
C'est possible si tu arrives à contacter l'intégralité des contributeurs. En pratique dès que ton projet dure un peu c'est compliqué (ou alors il faut réécrire des trucs, ce qui peut être compliqué selon les cas)…
[^] # Re: Ah si ils l'aiment l'open source...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Redis Open Source bronsonisé. Évalué à 6 (+4/-0).
En fait dans les exemples que tu présentes, il me semble que seul Redis est le coeur de métier de son éditeur, son gagne-pain.
Le problème c'est quand un éditeur gagne sa vie avec son produit et que des concurrents viennent le concurrencer. Kubernetes, Cassandra etc il me semble que le business des éditeurs de ces solutions ne repose pas sur la monétisation des outils qu'ils ont développé.
Ça change tout.
[^] # Re: Trop tard ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Eliane Domingos : nouvelle présidente de The Document Foundation. Évalué à 4 (+2/-0).
Je pense que tu n'es pas bien au fait du quotidien dans de nombreuses administrations et services publics.
Libreoffice mais aussi thunderbird et roundcube ont remplacé un certain volume de licences Microsoft.
Ça ne fait pas forcément beaucoup de bruit mais le mouvement est là …
[^] # Re: Changement de licence
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Redis Open Source bronsonisé. Évalué à 3 (+1/-0).
Ça ne t'empêche pas de garder le code libre : ça te permet juste en plus de l'exploiter dans une version propriétaire.
Les commit faits en MIT restent disponibles en MIT.
[^] # Re: GUI pour python.
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 4 (+2/-0).
J'avais vu cette page mais je n'avais pas compris les choses comme ça. Mais effectivement, avec ta lecture ça me semble logique et je comprends la même chose maintenant.
[^] # Re: GUI pour python.
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 5 (+3/-0).
Je ne comprends pas bien la licence. D'après GitHub c'est du GPLv3, d'après le site c'est GPLv3 pour l'embarqué et royalties free pour web et desktop.
[^] # Re: Thingiverse
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Où publier des modèles (pour impression) 3D dans l'esprit du logiciel libre . Évalué à 2 (+0/-0).
Intéressant ; est-ce que tu vois un site qui serait mieux ? Ou "c'est pas top mais c'est le moins pire" ?
[^] # Re: Ce que j'utilise au boulot principalement
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Vendeur de matériel informatique pour entreprise. Évalué à 2 (+0/-0).
D'ailleurs, pour Actual Systèmes, c'est dans les colonnes du forum que Tonio nous l'avait suggéré.
[^] # Re: L
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 4.
ah ah. J'ai remarqué ;) C'est pas un soucis :-D
C'est le risque en publiant sur linuxfr, et c'est aussi l'avantage de cet espace : les échanges peuvent digresser et c'est ce qui en fait tout l'intérêt. (raphj n'aurait peut-être pas partagé son script sans mon journal, et manifestement ça intéresse donc c'est très bien comme ça)