Un produit sous GPL, ça peut virer au proprio tout autant qu'un produit sous MIT.
Seulement si l'éditeur demande de signer un amendement où tu lui cède la propriété intellectuelle sur tes contributions (ou le bénéfice de celle-ci).
Sur un soft GPL qui a reçu de nombreuses contribution, il est sinon quasi impossible de changer de licence (et c'est bien une garantie pour les contributeurs)
Perso j'aime beaucoup ce pattern (mais sans abuser bien sur). Pour moi ça a du sens dés que l'on a des fichiers de configuration un peu long.
Tu n'as pas envie de te retrouver avec un conflit de apt lorsque tu change de version. La plupart du temps tu veux changer deux ou trois variables. En le faisant dans ton conf.d tu vois facilement ce que tu as changé et tu profite des bonnes pratiques par défaut de ta distribution.
Je met même mes fichiers de conf dans un git dans /opt avec un lien symbolique dans /etc et ce pattern devient encore plus intéressant.
J'ai découvert aussi avec systemd comment tu peux faire un systemd edit mon-service, qui crée (ici pour un service système) /etc/systemd/system/mon-service.service.d/override.conf qui te permet de changer des paramètres du service par défaut (et tu peux bien sur avoir plusieurs fichiers). Là aussi ça te permet de faire des variations tout en conservant tout ce le super travail fait par l'empaqueteur.
Vous devriez peut être parler avec le projet https://tauri.app/ qui, il me semble, a pour but de permettre un niveau de sécurité suffisant pour faire du html en desktop.
Perso je trouve XDG très bien car ça devrait permettre de sélectionner simplement les bons dossiers pour les sauvegardes, changement d'ordinateur etc.
Mais en pratique ce n'est malheureusement pas respecté par certains programmes qui mettent leur cache n'importe où… (et pas juste quelques fichiers…).
Même grief pour flatpak qui, au lieu de monter proprement les bons dossiers, met tout au même endroit pour chaque programme (il me semble en tout cas), à mon avis c'est bien dommage.
Pour moi ce serait pourtant simple: soumettre aux obligations celui qui vend le logiciel, pas celui qui l'a produit (après à celui qui vend un logiciel tiers de s'assurer que les obligations seront tenu).
Pour être sur: tu as vu que c'est 26€ c'est le prix d'un abonnement pour 1 an (pas 1 mois). Vu l'importance de la fiabilité du mail, je suis un peu surpris que tu penses que c'est uniquement pour les pros !
Oui mais j'avoue que je préférerais une limite journalière "dure" plus haute (genre 200 mails) qui suffisent tout de même à éviter les spammeurs et une limite réelle (lissée sur un mois) qui corresponde à 35 e-mails / jours. On pourrait, si on risque de dépasser la limite, être averti par mail à temps (mail à j-7, j-3, j-1) avec une invitation à passer au plan supérieurs… ou blocage au début du mois suivant pour x jours (pour résorber le trop envoyé) ?
Au pire il faut que ce soit manuel au début, les cas de dépassement brutaux seront ama très rares.
j'avoue que perso, c'est aussi ce qui me bloque d'emblée. Que se passe t'il si un jour je dois envoyer vraiment plus de 35 mails, ce qui peut être le cas le jour de mon anniversaire, en réponse, ou pour envoyer une invitation, ou lors de la préparation d'un évènement. C'est juste pas possible de me sentir bloqué de cette manière !
Yes, en tant que moule, je veux ajouter mon merci car je lis pas mal linuxfr et c'est une bonne source d'information et il y a un certain sens de communauté (même si les commentaires sont parfois assez brusques).
Un grand grand merci aux développeurs, aux modérateurs, à ceux qui contribuent des contenus et à toute forme de contribution.
Mon compte a été créé en 2003, mais je pense que je lisais déjà de temps en temps deux ou trois ans avant !
Ce genre d'application est aussi implémentable avec odoo. Il faut une équipe technique un peu motivé et un bon accompagnement, mais odoo est vraiment pensé pour créer des applications métier de ce type, avec une base déjà faite.
Ça vaut le coup si le module helpdesk (avec quelques autres modules éventuels) couvre déjà une bonne partie de ton besoin.
Il y a vraiment une API complète et des possibilités d'extensions dans tous les sens (actions serveurs, templates, ajouts de champs, etc.).
Oui il est pas mal du tout, il y a la notion d'attribution, d'équipe, de temps de résolution/escalade, des modèles, etc. C'est vraiment fait pour du support.
J'ai oublié de dire que par contre le site est très utilisé par nos utilisateurs avancés qui structurent l'information, corrigent les erreurs, etc. donc ça reste un outil très important.
Aujourd'hui l'application est vraiment complémentaire du site:
L'application mobile permet de scanner (ce que ne permet pas le site web)
L'application mobile est plus simple pour contribuer des images des produits (chose essentielle, c'est notre "source")
Les gens qui viennent sur le site sont plus "de passage", alors que l'application offre un publique plus engagé
Pour passer le site web en PWA et à une ergonomie mobile friendly (côté édition), il y aurai malheureusement un très gros boulot, mais toute contribution est bienvenue :-).
Oui tu es d'abord censé "retirer la ligne" (state absent au lieu de present) puis retirer la tâche.
On est d'accord, et je n'ai jamais dit que ce devait être magique, mais vraiment il y a des commandes où cet état présent/absent n'est pas géré par la commande. (bon en tout cas à l'époque où je l'utilisais).
C'est peut être aussi les rôles qui manquent parfois de maturité (et n'ont pas de vrai désinstallation).
Au final je trouve en tout cas que la promesse de "déclarer un état" n'est que très peu tenue.
Bravo pour votre projet. Monkeyble est sûrement tout à fait utile pour améliorer les playbook, mais ça ne me semble pas suffisant.
les ressources Ansible sont des "modèles d'états souhaités"
Perso ce qui m'a éloigné de Ansible c'est justement que cette phrase est fausse ! Rare sont les modules Ansible vraiment écrits comme ça.
(attention, mon expérience date un peu, si des choses ont changé c'est super)
Un des manques criant, par exemple, est le nettoyage des tâches supprimées (si j'enlève une tâche qui ajoute une ligne dans un fichier de conf, cette ligne restera là où elle a été mise), il faudrait plutôt que Ansible gère un état on/off.
Pour assurer sa maxime, Ansible devrait drastiquement limiter les modules à ceux capable de gérer ces cas là, mais ce n'est pas vrai de la plupart des modules de base même…
J'ai beaucoup souffert à déverminer des playbook qui avait fait l'objet de maintenance, qui pouvait run sur la machine de prod, mais était incapable de ré-installer une machine à partir de zéro… ou le contraire !
Bref perso je suis bien plus content de l'approche Docker pour le moment: rebâtir tout de zéro à chaque fois, sans arrêt ! (mais oui, ok, Docker ne va pas faire l'install du système sosu jacent, donc il faut un truc, mais je le limite au maximum)
Si je devais faire du déploiement automatisé je chercherais autre chose que Ansible, peut être pyinfra pour éviter le cauchemar des yaml imbriqués les uns dans les autres (et qui s'appellent tous "main.yml" ;-) ).
Déjà savoir qu'un playbook qui run jusqu'au bout c'est un bon signe, car le playbook peut lui même contenir les tests que l'environnement déployé fonctionne (c'est mieux en général !) par exemple avec un check sur une url publique, ou une petite requête BDD, etc.
Ça me semble vraiment une piste intéressante pour développer des apps décentralisées sans trop changer de paradigme de programmation.
Décentralisé à la https://scuttlebutt.nz/ ou tu te connecte aux autres occasionnellement (capacité d'être off-grid, très intéressant pour une décentralisation jusqu'au niveau de l’ordinateur personnel).
Pareil pour le monde mobile où tu veux pouvoir fonctionner en off-line puis push tes modifications. (je sais que c'était un des cas d'utilisation de couchDB sur mobile).
[^] # Re: Pendant ce temps-là chez Microsoft
Posté par Alex G. . En réponse au journal Redis Open Source bronsonisé. Évalué à 2 (+0/-0).
Seulement si l'éditeur demande de signer un amendement où tu lui cède la propriété intellectuelle sur tes contributions (ou le bénéfice de celle-ci).
Sur un soft GPL qui a reçu de nombreuses contribution, il est sinon quasi impossible de changer de licence (et c'est bien une garantie pour les contributeurs)
[^] # Re: Pendant ce temps-là chez Microsoft
Posté par Alex G. . En réponse au journal Redis Open Source bronsonisé. Évalué à 3 (+1/-0). Dernière modification le 28 mars 2024 à 11:14.
Je serais curieux de savoir s'il y a toutes les fonctionnalités de Redis !
Perso j'aime plus redis pour ses capacité de synchronisation inter-processus que comme cache.
C'est à dire:
- les primitives de verrou
- le Publish-subscribe (répartition de messages)
- les events stream (flux d'évènements)
- le rate limiting à base de Seau percé
Remarque: Le produit de M$ aussi c'est du MIT, donc ça peut virer proprio à un moment donné !
[^] # Re: Répertoires /conf.d/
Posté par Alex G. . En réponse au journal [ HS ] ... enfin, pas tant que ça.. Évalué à 7 (+5/-0).
Perso j'aime beaucoup ce pattern (mais sans abuser bien sur). Pour moi ça a du sens dés que l'on a des fichiers de configuration un peu long.
Tu n'as pas envie de te retrouver avec un conflit de apt lorsque tu change de version. La plupart du temps tu veux changer deux ou trois variables. En le faisant dans ton conf.d tu vois facilement ce que tu as changé et tu profite des bonnes pratiques par défaut de ta distribution.
Je met même mes fichiers de conf dans un git dans /opt avec un lien symbolique dans /etc et ce pattern devient encore plus intéressant.
J'ai découvert aussi avec systemd comment tu peux faire un systemd edit mon-service, qui crée (ici pour un service système) /etc/systemd/system/mon-service.service.d/override.conf qui te permet de changer des paramètres du service par défaut (et tu peux bien sur avoir plusieurs fichiers). Là aussi ça te permet de faire des variations tout en conservant tout ce le super travail fait par l'empaqueteur.
[^] # Re: Et le lieu !
Posté par Alex G. . En réponse au journal Hackathon Perl / Open Food Facts à Paris les samedi 23 et dimanche 24 mars 2024. Évalué à 3 (+1/-0).
Oups, corrigé sur la page en lien, au moins !
# Et la date !
Posté par Alex G. . En réponse au journal Hackathon Perl / Open Food Facts à Paris les samedi 23 et dimanche 24 mars 2024. Évalué à 3 (+1/-0).
Voilà ce qui arrive de copier coller le texte de l'Agenda du libre… j'ai oublié de préciser la date:
le samedi 23 et dimanche 24 mars ! (de 10h à 18h environ).
[^] # Re: Très bon logiciel, avec quelques faiblesses côté ergonomie/intégration
Posté par Alex G. . En réponse à la dépêche Sortie de passbolt v4.5 : Gestion de l'expiration des mots de passe et autres améliorations. Évalué à 3 (+1/-0).
https://tauri.app/v1/references/architecture/security pour plus d'info côté sécurité.
[^] # Re: Très bon logiciel, avec quelques faiblesses côté ergonomie/intégration
Posté par Alex G. . En réponse à la dépêche Sortie de passbolt v4.5 : Gestion de l'expiration des mots de passe et autres améliorations. Évalué à 2 (+1/-1).
Vous devriez peut être parler avec le projet https://tauri.app/ qui, il me semble, a pour but de permettre un niveau de sécurité suffisant pour faire du html en desktop.
# Moi ce qui m'énerve le plus c'est des données de cache dans .var ou .local :-(
Posté par Alex G. . En réponse au lien $HOME, Not So Sweet $HOME. Évalué à 6.
Perso je trouve XDG très bien car ça devrait permettre de sélectionner simplement les bons dossiers pour les sauvegardes, changement d'ordinateur etc.
Mais en pratique ce n'est malheureusement pas respecté par certains programmes qui mettent leur cache n'importe où… (et pas juste quelques fichiers…).
Même grief pour flatpak qui, au lieu de monter proprement les bons dossiers, met tout au même endroit pour chaque programme (il me semble en tout cas), à mon avis c'est bien dommage.
[^] # Re: Pulumi
Posté par Alex G. . En réponse au lien HashiCorp adopts Business Source License. Évalué à 2.
Est-ce que c'est réellement plus libre, ou ça le restera ?
PyInfra est plus confidentiel mais pas mal aussi.
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Alex G. . En réponse à la dépêche CRA: L’Europe va-t-elle jeter le bébé du logiciel libre avec l’eau du bain de la cyber-insécurité ?. Évalué à 4.
Pour moi ce serait pourtant simple: soumettre aux obligations celui qui vend le logiciel, pas celui qui l'a produit (après à celui qui vend un logiciel tiers de s'assurer que les obligations seront tenu).
[^] # Re: Concernant les limites dures sur le nb de mails envoyés ...
Posté par Alex G. . En réponse au journal galae, le service email qui vous veut du bien. Évalué à 3.
Génial ! Je m'étais de toute façon quand même déjà inscrit :-)
[^] # Re: 35 mails pour moi c'est déjà trop
Posté par Alex G. . En réponse au journal galae, le service email qui vous veut du bien. Évalué à 4.
Pour être sur: tu as vu que c'est 26€ c'est le prix d'un abonnement pour 1 an (pas 1 mois). Vu l'importance de la fiabilité du mail, je suis un peu surpris que tu penses que c'est uniquement pour les pros !
[^] # Re: Comment estimer le nombre de mails que j'envoie par jour ?
Posté par Alex G. . En réponse au journal galae, le service email qui vous veut du bien. Évalué à 4.
Oui mais j'avoue que je préférerais une limite journalière "dure" plus haute (genre 200 mails) qui suffisent tout de même à éviter les spammeurs et une limite réelle (lissée sur un mois) qui corresponde à 35 e-mails / jours. On pourrait, si on risque de dépasser la limite, être averti par mail à temps (mail à j-7, j-3, j-1) avec une invitation à passer au plan supérieurs… ou blocage au début du mois suivant pour x jours (pour résorber le trop envoyé) ?
Au pire il faut que ce soit manuel au début, les cas de dépassement brutaux seront ama très rares.
[^] # Re: Comment estimer le nombre de mails que j'envoie par jour ?
Posté par Alex G. . En réponse au journal galae, le service email qui vous veut du bien. Évalué à 3.
j'avoue que perso, c'est aussi ce qui me bloque d'emblée. Que se passe t'il si un jour je dois envoyer vraiment plus de 35 mails, ce qui peut être le cas le jour de mon anniversaire, en réponse, ou pour envoyer une invitation, ou lors de la préparation d'un évènement. C'est juste pas possible de me sentir bloqué de cette manière !
# Merci
Posté par Alex G. . En réponse à la dépêche Vingt-cinq ans de LinuxFr.org. Évalué à 5.
Yes, en tant que moule, je veux ajouter mon merci car je lis pas mal linuxfr et c'est une bonne source d'information et il y a un certain sens de communauté (même si les commentaires sont parfois assez brusques).
Un grand grand merci aux développeurs, aux modérateurs, à ceux qui contribuent des contenus et à toute forme de contribution.
Mon compte a été créé en 2003, mais je pense que je lisais déjà de temps en temps deux ou trois ans avant !
Joyeux anniversaire !
# Autre piste odoo
Posté par Alex G. . En réponse au journal Opportunité de réinventer la roue... et la gestion de tickets ?. Évalué à 5.
Ce genre d'application est aussi implémentable avec odoo. Il faut une équipe technique un peu motivé et un bon accompagnement, mais odoo est vraiment pensé pour créer des applications métier de ce type, avec une base déjà faite.
Ça vaut le coup si le module helpdesk (avec quelques autres modules éventuels) couvre déjà une bonne partie de ton besoin.
Il y a vraiment une API complète et des possibilités d'extensions dans tous les sens (actions serveurs, templates, ajouts de champs, etc.).
[^] # Re: Ou zammad
Posté par Alex G. . En réponse au journal Opportunité de réinventer la roue... et la gestion de tickets ?. Évalué à 3.
Oui il est pas mal du tout, il y a la notion d'attribution, d'équipe, de temps de résolution/escalade, des modèles, etc. C'est vraiment fait pour du support.
Côté intégration, c'est très paramétrable, il y a une API bien documentée et des webhooks.
PS: attention pour la doc, bien partir de https://zammad.org/documentation car il y a des docs dédiés à chaque aspects.
[^] # Re: Web / application
Posté par Alex G. . En réponse à la dépêche Appel à participation pour dessiner l'app Open Food Facts de demain . Évalué à 7.
J'ai oublié de dire que par contre le site est très utilisé par nos utilisateurs avancés qui structurent l'information, corrigent les erreurs, etc. donc ça reste un outil très important.
[^] # Re: Web / application
Posté par Alex G. . En réponse à la dépêche Appel à participation pour dessiner l'app Open Food Facts de demain . Évalué à 10.
Aujourd'hui l'application est vraiment complémentaire du site:
Pour passer le site web en PWA et à une ergonomie mobile friendly (côté édition), il y aurai malheureusement un très gros boulot, mais toute contribution est bienvenue :-).
# Cool pour XWiki
Posté par Alex G. . En réponse à la dépêche Et pendant ce temps là, en Allemagne... The Sovereign Workplace. Évalué à 10.
Qui est un éditeur français :-)
[^] # Re: Intéressant mais est-ce suffisant ?
Posté par Alex G. . En réponse à la dépêche Présentation de Monkeyble: Framework de test bout en bout pour Ansible. Évalué à 2.
On est d'accord, et je n'ai jamais dit que ce devait être magique, mais vraiment il y a des commandes où cet état présent/absent n'est pas géré par la commande. (bon en tout cas à l'époque où je l'utilisais).
C'est peut être aussi les rôles qui manquent parfois de maturité (et n'ont pas de vrai désinstallation).
Au final je trouve en tout cas que la promesse de "déclarer un état" n'est que très peu tenue.
# Intéressant mais est-ce suffisant ?
Posté par Alex G. . En réponse à la dépêche Présentation de Monkeyble: Framework de test bout en bout pour Ansible. Évalué à 3.
Bravo pour votre projet. Monkeyble est sûrement tout à fait utile pour améliorer les playbook, mais ça ne me semble pas suffisant.
Perso ce qui m'a éloigné de Ansible c'est justement que cette phrase est fausse ! Rare sont les modules Ansible vraiment écrits comme ça.
(attention, mon expérience date un peu, si des choses ont changé c'est super)
Un des manques criant, par exemple, est le nettoyage des tâches supprimées (si j'enlève une tâche qui ajoute une ligne dans un fichier de conf, cette ligne restera là où elle a été mise), il faudrait plutôt que Ansible gère un état on/off.
Pour assurer sa maxime, Ansible devrait drastiquement limiter les modules à ceux capable de gérer ces cas là, mais ce n'est pas vrai de la plupart des modules de base même…
J'ai beaucoup souffert à déverminer des playbook qui avait fait l'objet de maintenance, qui pouvait run sur la machine de prod, mais était incapable de ré-installer une machine à partir de zéro… ou le contraire !
Bref perso je suis bien plus content de l'approche Docker pour le moment: rebâtir tout de zéro à chaque fois, sans arrêt ! (mais oui, ok, Docker ne va pas faire l'install du système sosu jacent, donc il faut un truc, mais je le limite au maximum)
Si je devais faire du déploiement automatisé je chercherais autre chose que Ansible, peut être pyinfra pour éviter le cauchemar des yaml imbriqués les uns dans les autres (et qui s'appellent tous "main.yml" ;-) ).
[^] # Re: C'est quoi la grande différence avec Molécule ?
Posté par Alex G. . En réponse à la dépêche Présentation de Monkeyble: Framework de test bout en bout pour Ansible. Évalué à 3.
Déjà savoir qu'un playbook qui run jusqu'au bout c'est un bon signe, car le playbook peut lui même contenir les tests que l'environnement déployé fonctionne (c'est mieux en général !) par exemple avec un check sur une url publique, ou une petite requête BDD, etc.
# Je partage car j'ai trouvé ça intéressant
Posté par Alex G. . En réponse au lien Open Source : qui a peur de l’éditeur ? (Blog de Bluemind). Évalué à 3.
Il me semble que c'est pas mal écrit.
[^] # Re: Idée interessante
Posté par Alex G. . En réponse au lien Dolt : une base de données versionnée. Évalué à 2.
Ça me semble vraiment une piste intéressante pour développer des apps décentralisées sans trop changer de paradigme de programmation.
Décentralisé à la https://scuttlebutt.nz/ ou tu te connecte aux autres occasionnellement (capacité d'être off-grid, très intéressant pour une décentralisation jusqu'au niveau de l’ordinateur personnel).
Pareil pour le monde mobile où tu veux pouvoir fonctionner en off-line puis push tes modifications. (je sais que c'était un des cas d'utilisation de couchDB sur mobile).