Alex G. a écrit 651 commentaires

https://nlnet.nl/project/KDEPlasma-Wayland/ pour un exemple parlant, parmi tant d'autres.

Le projet NGI0 sert aussi à financer des projets hardware et peut financer des projets de drivers (pourvu qu'un projet candidate). Ça se voit bien ici: https://nlnet.nl/thema/

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)

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é !

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.

Oups, corrigé sur la page en lien, au moins !

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).

https://tauri.app/v1/references/architecture/security pour plus d'info côté sécurité.

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.

Est-ce que c'est réellement plus libre, ou ça le restera ?

PyInfra est plus confidentiel mais pas mal aussi.

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).

Génial ! Je m'étais de toute façon quand même déjà inscrit :-)

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 !

Joyeux anniversaire !

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.

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.

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 :-).

Qui est un éditeur français :-)

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.