On a AUCUNE information sur ce taux, puisqu'il dépend du nombre total de porteurs sains qui n'est pas mesuré …
On n'a pas de mesure très précise mais on commence quand même à avoir une idée de l'ordre de grandeur. Il y a eu des cas où on a testé toute la population après une vague d'épidémie (paquebot de croisière mis en quarantaine, quelques petites villes italiennes pour lesquelles la vague est passée). L'ordre de grandeur, c'est environ 50% des contaminés ne vont pas développer de symptômes (et 50% des contaminations par une personne qui va développer des symptômes se fait avant l'apparition des symptômes => 75% des contaminations se fait par une personne qui ne présente pas de symptôme). Quand je parle de 50%, ça sera peut-être 30% ou 70%, mais en tout cas, ça paraît très peu probable qu'il y ait dix fois plus de contaminés sans symptômes.
Bien sûr que les hôpitaux ont une influence sur ce taux, mais ce n'est pas ce que je dis : La forme de la courbe ne dépend pas de ce taux … On peut donc facilement déterminer le moment où la courbe s'infléchie, qqs le nombre de lits.
La forme de la courbe dépend de R0, qui dépend des mesures de confinement. Et la courbe du nombre de malades ne dépend pas du nombre de lits. Le nombre de morts, par contre, dépend du nombre de malades et du nombre de lits. Et c'est très important de respecter les mesures de précaution pour limiter le nombre de malades, et surtout éviter de surcharger les hôpitaux.
Une fois que 20 % de la population est infectée
On est encore très très loin d'avoir 20% de la population infectée.
NON, les mesures de confinement, même prises trop tard comme en Italie, ont des effets très importants pour limiter le nombre de malades et surtout le nombre de morts.
on peut établir que nombre d'infectés >> nombre de mort
On est autour d'un taux de mortalité de 1% pour les malades tant que les hôpitaux ne sont pas débordés, et de 5% ensuite. C'est énorme et on voit l'importance de ne pas surcharger les hôpitaux. Les mesures de confinement sont super importantes pour ça. J'encourage tout le monde à suivre au mieux les recommandations des scientifiques sur les mesures de distanciation sociale.
Je ne pense pas qu'un logiciel « weboob as an API » mettrait B-I sur la paille. Ça peut convenir pour des auto-hébergés, mais c'est loin d'être suffisant pour proposer ce service à une échelle plus vaste. B-I utilise un mélange de récupération des données via les API DSP2 et du scraping. Pour la partie DSP2, il y a des contraintes légales et financières pas évidentes. Pour le scraping, il faut faire attention à ne pas se faire blacklister les adresses IP. B-I utilise également des fermes de simulateurs android avec les apps mobiles des banques pour scrapper certaines données, et c'est pas weboob qui est utilisé dans ce cas.
Pour moi, si c'est pour avoir un n-ième fournisseur d'agrégateur bancaire propriétaire, j'utilise l'une de mes banques, elles proposent toutes la fonction maintenant.
Je suis d'accord : si Cozy ne doit servir que d'agrégateur bancaire, sa valeur est faible. La force de Cozy est dans sa diversité, dans sa capacité à avoir des connecteurs pour importer des factures, la synchro des photos, la prise de notes, etc.
Pour la question joker, le contexte n'est pas très favorable et ce n'est pas là que l'on veut mettre la priorité.
La directive européenne DSP2 qui devait aider les gens à avoir plus facilement accès à leurs données a été retournée par les banques : elles sont très en retard pour proposer les API, mais elles ont déjà mises en place de l'authentification à 2 facteurs, avec des règles contraignantes pour nous. Pour le moment, même en passant par B-I, c'est compliqué, on a pas mal d'erreurs. Du coup, on est plutôt dans une position d'attente, en espérant que la situation s'améliore du côté des banques.
Ensuite, weboob n'est pas si simple à intégrer avec Cozy et ne permet pas de faire tout ce que l'on fait. Il manque par exemple la catégorisation bancaire. On a commencé à travaillé sur le sujet de la catégorisation bancaire (indépendamment de la source des données) dans l'espoir que des contributeurs s'attaquent à la partie connecteurs.
Enfin, on a peu d'auto-hébergés et peu de contributions, ce qui ne nous encourage vraiment pas à faire du spécifique pour les auto-hébergés. On préfère que nos développements profitent à plus de monde. On a sorti l'application notes et le gestionnaire de mots de passe, qui peuvent être utilisés aussi bien par les auto-hébergés que pour les instances chez Cozy Cloud.
Qu'appelles-tu multi-utilisateur ? Une installation de Cozy sur un serveur peut servir pour plusieurs utilisateurs. Chaque utilisateur a alors son instance, avec son nom de domaine, et peut partager des répertoires et documents avec d'autres utilisateurs.
Pour un contexte en entreprise où l'on veut avoir des groupes d'utilisateurs, avec du LDAP, des règles pour donner des permissions, et des notions de rôles pour certains utilisateurs, Cozy est effectivement mal adapté. Et je conseille plutôt NextCloud pour ce cas d'usage. On reste une petite équipe et on ne peut pas tout faire, et sur ce terrain, NextCloud a trop d'avance pour que ça fasse sens de lutter.
Chez Cozy, on reste plutôt centré sur une approche où chaque utilisateur est maître de ses données et va pouvoir regrouper dans un seul espace des données provenant de plusieurs contextes, dont potentiellement un contexte professionnel. On peut toucher des entreprises, mais c'est via d'autres angles : l'objectif est plutôt d'équiper les clients de ses entreprises avec un Cozy que les salariés.
J'ai en revanche une question à laquelle je n'ai toujours pas trouvé de réponse évidente: comment exporter les données ?
En particulier, sur le module CozyBank, via un export CSV pour faire au plus simple, via des call API pour des intégration sympas ? Via un mail au DPO pour demander un extract des données me concernant en leur possession ?
Si tu veux exporter les données, tu peux aller sur ton Cozy, puis dans l'application « Settings ». Il y a un bouton pour télécharger tes données (ça va t'envoyer un mail avec un lien vers une page où tu pourras télécharger tes données, généralement en plusieurs archives zip pour éviter d'avoir une très grosse archive dont le téléchargement prendrait plusieurs jours et qu'il faudrait reprendre depuis zéro si ça plante). Ça sera du JSON et pas du CSV pour les données extraites de la base de données.
Si tu préfères des API, on a ce qu'il faut. En fait, toutes les opérations que font les applications et connecteurs passent par des API. Pour la partie authentification et contrôle d'accès, tu peux passer par un client OAuth2. Et je pense que tu vas surtout être intéressé par les API du Data System, qui reprennent les API de notre moteur de base de données (CouchDB). Et les données bancaires ont un formalise décrit sur https://docs.cozy.io/en/cozy-doctypes/docs/io.cozy.bank/.
Je n'ai pas fais de vérification mais pour que des logiciels de synchronisation aient une chance de fonctionner il faut qu'ils traquent les close et move via inotify plutôt que de faire la copie bêtement.
Je confirme, c'est l'idée. C'est bien entendu plus compliqué que ça (FsWatcher, l'équivalent de inotify pour macOS n'a pas d'événements pour les close par exemple), mais en gros, ça revient à écouter les changements sur une partie de l’arborescence, et quand un fichier change, on attend un peu après les derniers changements, puis on va lire progressivement le fichier et envoyer ça au serveur.
Si non tu ne peux pas non plus t'en servir pour les fichiers LibO par exemple et ça commence à être problématique car c'est un peu leur cas d'usage principale.
En général, la plupart des logiciels gardent les documents des utilisateurs ouverts (au sens avec un file handler) pendant des périodes de temps très courtes. Au moment où ils font la sauvegarde, ils ouvrent le fichier, écrivent, puis referment le fichier. Pas mal de logiciels passent par un fichier temporaire : ils ouvrent un fichier temporaire, écrivent dedans, le referme, puis déplace ensuite le fichier temporaire au-dessus de l'ancienne version.
Encore une fois, c'est l'idée générale. En vrai, c'est plus compliqué que ça. Je recommande la lecture de https://danluu.com/deconstruct-files/ pour ceux qui veulent creuser le sujet.
De l'autre côté des logiciels comme keypass peuvent limiter fortement les risques. En manipulant correctement leur fichier, ils presque n'y appliquer que des opérations automatiques.
Ils pourraient, mais, à ma connaissance, ce n'est pas comme ça qu'ils fonctionnent. Ils ont un mode de fonctionnement qui ressemble plutôt à une base de données, mais sans la même qualité d'implémentation. Le fichier est ouvert en permanence pendant que le logiciel tourne, souvent avec un second fichier qui sert de verrou (« lock-file »). Les écritures ne se font pas séquentiellement du début vers la fin, mais en sautant d'un endroit à un autre. Ils n'ont pas de journal d'écriture qui permet de repartir en cas de problème. Ils pourraient utiliser sqlite3 plutôt que le format de fichiers kdbx… mais ils ne le font pas.
Même avec tout ça, il faut qu'ily ait une copie incorrecte qui se passe sans avoir de copie correcte quelques secondes plus tard. C'est possible, mais ça réduit encore les risques.
J'avais creusé la question pour le client desktop de Cozy et j'étais tombé sur beaucoup de messages dans des forums de personnes qui avaient perdu leur base de mots de passe keepass à cause de ce genre de problème. Ce n'est pas qu'un problème théorique. Après, c'est aussi possible que ça reste très rare et que mon avis soit biaisé parce que j'ai justement creusé les forums pour aller chercher ce genre de problèmes.
Ma question est naïve, peut-être est-ce parce que mes besoins sont limités, mais quelqu'un pourrait-il m'expliquer ce qu'apporte le fonctionnement client/serveur ?
Je ne prétends pas être un expert et je ne connais que de nom KeepassXC, mais de ce que j'en comprends, il y a deux modes de synchronisation : soit l'utilisateur fait manuellement une action pour synchroniser ses mots de passe, soit ça se fait automatiquement.
Si c'est manuel, ça marche bien mais c'est vite chiant.
Si c'est automatique, il faut faire attention à ne pas corrompre la base de données. En mode client/serveur, le serveur garantit ça. Si c'est de la synchronisation via Dropbox, NextCloud ou un autre outil de synchronisation de fichiers, il peut arriver qu'une écriture de l'outil de gestion de mots de passe arrive au même moment qu'une synchronisation et que la base de données se retrouve ainsi corrompue. Ou qu'un fichier de lock soit synchronisé et empêche d'utiliser son gestionnaire de mots de passe sur un ordinateur parce qu'il est ouvert sur un autre.
J'aurais tendance à dire que pour un geek, l'approche keepass/keepassxc est séduisante. Pour le commun des mortels, passer par un client/serveur est plus simple.
Il y a ensuite la question de s'auto-héberger ou non. Tu dis que ce n'est pas à la portée de tout le monde. Je suis bien d'accord. Mais avoir un serveur NextCloud et faire des sauvegardes régulières ne l'est pas non plus. Ça me semble être grosso modo le même niveau de difficultés dans les deux cas. J'entends que le serveur NextCloud peut servir à d'autres choses et que, quitte à s'embêter, autant que ce soit le plus utile possible.
Quand à passer par une clé usb, un disque dur ou du samba, j'ai du mal à voir comment faire ça et avoir son trousseau de clés à jour sur son smartphone, ce qui reste un usage très important des gestionnaires de mots de passe (peut-être en partie parce que c'est plus compliqué de taper un mot de passe sur un smartphone que sur un clavier physique).
Oui, l'implémentation officielle s'appuie sur Microsoft SQL Server. C'est pourquoi je conseille aux personnes qui veulent s'auto-héberger de plutôt utiliser la version en Rust, qui elle, est compatible avec sqlite, MySQL et PostgreSQL (de mémoire).
Oui, j'ai réimplémenté la partie serveur de bitwarden dans Cozy. On peut utiliser les clients officiels de Bitwarden avec, mais c'est un peu compliqué de trouver comment se connecter (il faut passer par des options avancées pour saisir l'URL du serveur Cozy). C'est pourquoi, on travaille aussi sur des clients Cozy : ce sont des forks des clients officiels, avec quelques modifications d'interface, notamment pour simplifier la connexion. On propose également des passerelles entre le trousseau de clefs bitwarden et les comptes utilisés pour les connecteurs.
Tout n'est pas encore fini, mais c'est déjà utilisable. Vous pouvez installer l'app Cozy Pass sur votre instance Cozy pour vous lancer !
Oui, le pourcentage de chances d'être hospitalisé est plus important pour déterminer si le système de santé peut faire face à la situation. Mais, ici aussi, je me demande d'où sort le 20%. Pour moi, ça devrait être 8% : jusqu'ici, on parlait de 80% des contaminés sont des malades avec des symptômes, et 10% des malades avec symptômes nécessitent une hospitalisation.
D'où vient ce pourcentage ? Il me semblait que, dans le précédent journal, on parlait de 20% de porteurs sains, donc 80% de chances de développer des symptômes.
S'il on multiplie quelque chose par 0,8, on le diminue.
Tout à fait, on parle bien d'une diminution.
S'il s'agit de 80% de plus de cas dûs aux porteurs sains
Je pense que la confusion vient du mot « cas », dont le sens n'est pas le même selon que l'on inclut ou non les porteurs sains dedans.
Le billet explique qu'on va atteindre un certain nombre de personnes touchées par le virus au moment du pic qui dépend de R0. On suppose que l'évaluation de R0 ne change pas si on détecte des porteurs sains (ça a l'air d'être l'hypothèse prise par le billet, mais j'aurais bien aimé la voir détaillée). On peut donc dire que l'on aura n personnes touchées par le virus au moment du pic.
On sait également que 10% des personnes ayant des symptômes vont être des cas graves, et 2% des personnes ayant des symptômes vont mourir.
S'il n'y a pas de porteurs sains, il y a 100% des n personnes qui vont avoir des symptômes, 10% des n personnes qui vont être des cas graves et 2% des n personnes qui vont mourir.
S'il y a 20% de porteurs sains parmi les n personnes, ça ne fait plus que 80% des n personnes qui vont avoir des symptômes. On a bien multiplié par 0,8 le nombre de cas (personnes avec des symptômes). De même, il n'y aura que 10% des personnes avec symptômes qui vont devenir un cas grave, soit 10% des 80% des n personnes => 8% des n personnes. Et 2% des personnes avec symptômes, soit 2% * 0,8 = 1,6% des n personnes qui vont mourir.
Salut, je suis le développeur principal de la version Ruby on Rails du site. Ces dernières 4 ou 5 années, je ne suis plus très actif (mon dernier commit remonte à 6 mois par exemple), donc c'est vraiment bienvenu que d'autres personnes s'intéressent au code et proposent des PR.
Le gros du code a été écrit en 2009 et 2012. Ça remonte pas mal et certaines choses ont mal vieillies (mais moins que ce que l'on pourrait craindre). Dans l'ensemble, Ruby on Rails fait du bon boulot et le code est dans un état correct. Il y a des parties qui ont été écrites avant que Ruby on Rails ne propose une solution à ça, et si on réécrivait ça aujourd'hui, ça serait beaucoup plus simple en utilisant la solution de Ruby on Rails (par exemple, on n'utilise pas ActiveJob pour les jobs de publication des news sur twitter). Mais pour les parties qui ont mal vieillies, je pense plutôt à la doc et aux tests (ou plutôt l'absence de tests).
j'ai bien l'impression qu'il y a des tests automatisés
Non, il n'y en a plus. Il y en a eu par le passé, mais sans intégration continue et avec une couverture loin d'être suffisante. Du coup, ils ne servaient pas à grand chose, et quand ils ont cassé sur des mises à jour de Ruby on Rails ou d'autres gems, la solution la plus simple a été de retirer les tests cassés. À la fin, j'ai fini par tous les retirer.
Au delà du Readme, existe-t-il une aide à la prise en main du code LinuxFr ?
Pas vraiment (ou des trucs trop anciens pour être vraiment utiles), mais j'essaye de répondre aux questions que l'on me pose.
Peut-on proposer une pull request pour une entrée de suivi dont la note est de 0 ?
Oui, c'est possible (surtout s'il n'y a pas de commentaires avec un avis négatif dessus). C'est probablement préférable d'indiquer dans l'entrée de suivi que tu comptes proposer une PR. Globalement, on a plutôt tendance dans l'équipe à accepter facilement les contributions.
Y a-t-il un forum préférable pour poser des questions en lien avec le développement du site LinuxFr ?
Je dirais que le suivi est ce qui s'en rapproche le plus. Il y a eu une liste de diffusion par mails pour ça, mais je crois qu'elle n'existe plus.
Pour proposer une mise à jour du Readme de https://github.com/linuxfrorg/linuxfr.org/, une pull request suffit-elle ou bien est-il préférable d'ouvrir au préalable une entrée de suivi sur LinuxFr ?
Une pull request suffit pour ça.
mysql> CREATE USER 'linuxfr_rails'@'localhost' IDENTIFIED BY 'asecretpassword';
Access denied for user 'linuxfr_rails'@'localhost' (using password: NO)
Dans le fichier config/database.yml, il y a une section development qu'il faut modifier en :
Oui, mais la simplification est un moyen, mais une fin en soi. Sinon, il suffirait juste de supprimer complètement les retraites, difficile de faire plus simple !
Le gus essaye de simplifier, mais au passage, il casse des acquis sociaux. Pour la réforme des retraites, repousser l'âge à 64 ans quand on sait que le taux de chômage est élevé chez les personnes qui ont plus de 60 ans, ça va mettre des personnes dans la précarité.
Pour prendre une analogie, pour le code, on aime bien aussi la simplicité. Mais si quelqu'un arrive avec une demande de changements qui simplifie le code mais qui casse des tests unitaires, ça ne va pas être accepté.
Après, je ne dis pas, il y a aussi des gens qui ont eu des avantages qui ne paraissent plus légitimes aujourd'hui et qui ne veulent pas les lâcher. Mais je ne pense pas que ce soit la principale raison de l'opposition à la réforme des retraites.
et aussi qui s'adapte à l’espérance de vie pour pas se taper des changements tous les x ans
Mwais, on nous a déjà vendu ça à la dernière réforme des retraites et l'espérance de vie en France n'augmente vraiment pas très vite ces dernières années. Mais surtout, si on veut parler espérance de vie, il faudrait attaquer vraiment le sujet et pas juste de manière superficielle : il y a un très grand écart sur l'espérance de vie entre les cadres et les ouvriers. Est-ce que cela ne devrait pas se refléter dans l'âge de départ à la retraite (ou l'âge pivot) ?
Je maintiens que les erreurs de bonne foi ne rentrent pas dans le cadre de la fraude fiscale, et que faire un erreur en bonne foi ne fait pas de toi un fraudeur.
La notion d'écart fiscal recouvre 2 types d'irrégularités :
les erreurs volontaires (= la fraude fiscale)
les erreurs involontaires.
Moi je ne lis pas cela : "cette notion désigne la différence entre ce qui devrait être recouvré si la loi fiscale et sociale avait été parfaitement respectée et ce qui a été effectivement recouvré ."
Effectivement, l'état aurait dû percevoir des prélèvements qu'il n'a pas perçus à la fois pour la fraude fiscale et les erreurs involontaires.
Page 8 du rapport de synthèse.
Je trouve le diagramme de cette page assez clair. Il y a d'ailleurs une case rouge avec marqué dedans « Irrégularités volontaires » et libellé comme « Fraude ». Les « Irrégularités involontaires » sont dans une autre case.
Je pense aussi que tu as été trompé et donc entretenu aussi la confusion car dans un de tes précédents posts, tu parles d'améliorer la lutte contre la fraude fiscale et tu cites des montants de redressements en baisse (18Mds en 2013 et 16 Mds en 2018).
Je plaide coupable pour avoir entretenu la confusion : les montants des redressements sont effectivement pour la fraude et les erreurs involontaires. J'ai mis en avant ces chiffres car le rapport ne fournit pas de chiffres séparés pour les deux (en gros, ils disent que ce serait bien d'avoir les chiffres séparés mais que l'état n'a pas mis en place ce qu'il faut pour pouvoir les calculer).
Je parle effectivement de lutte contre la fraude fiscale, car elle me paraît plus importante et être une mesure plus juste aux yeux du plus grand nombre de citoyens français. Mais, à titre personnel, je serais très content si l'état français est capable de recouvrer plus d'argent sur les erreurs involontaires.
Moi, ça m'est arrivé. L'agence immobilière m'a demandé l'équivalent d'un mois de loyer (pour un studio) sur la caution. C'était très clairement abusif au vu des états des lieux entrants et sortants, et quand j'en ai discuté avec eux, ils m'ont proposé une réduction de 50€, puis de 100€. J'étais toujours fâché, et j'ai saisi la commission départementale de conciliation. Devant cette commission, ils ont accepté de me rendre les 2/3 de ce qu'ils avaient gardé de la caution. Je pense que si j'avais été devant la justice, j'aurais encore pu récupérer une centaine d'euros supplémentaires (mais ça m'aurait probablement coûté autant en frais et ça aurait pris longtemps).
Attention au terme "fraude fiscale" car il regroupe aussi l'erreur de bonne foi. Je cite le même rapport :
Le rapport dit très précisément le contraire : l'erreur de bonne foi existe, mais elle ne rentre pas dans la case « fraude fiscale ». Le rapport parle d'écart fiscal pour la somme de la fraude fiscale et des erreurs de bonne foi. On trouve également l'optimisation fiscale, qui est un ensemble de pratiques légales pour réduire les prélèvements fiscaux. Et s'il y a une limite qui est floue, c'est plutôt entre fraude fiscale et optimisation fiscale (toujours selon le rapport), car cela fait souvent intervenir des règles très complexes et cela joue beaucoup sur l'interprétation des lois.
Et quand je vois la complexité de notre système fiscal, une erreur est vite arrivée.
C'est un autre débat, mais je suis d'accord, notre système fiscal mériterait d'être plus simple : moins de niches fiscales et de cas particuliers, et des règles plus compréhensibles et accompagnées d'exemples pour les cas plus généraux.
Si ca se trouve, je suis un fraudeur.
De ce que tu as décris, ça n'a pas l'air d'être le cas. Enfin, sauf si tu nous dis que tu as monté 3 sociétés dans un paradis fiscal, que tu as un compte en Suisse dont le FISC n'est pas au courant et que ton jet privé de fonction te sert à aller tous les week-ends à Ibiza. Ou encore, que tu vends plein de trucs sur Amazon sans payer la TVA.
Je trouve même qu'il y a une inégalité devant l'impôt, car il est devenu incompréhensible pour la majorité (avis personnel).
Oui, c'est également mon avis. D'ailleurs, les études montrent que le taux effectif de prélèvement des impôts est plus bas pour les très riches que pour les tranches moyennes et qu'un des mécanismes qui permet d'y arriver est justement la possibilité qu'ils ont d'employer des fiscalistes pour profiter de cette complexité (je parle ici d'optimisation fiscale, la partie légale, mais la fraude n'est pas toujours très loin).
[^] # Re: modèle
Posté par Bruno Michel (site web personnel) . En réponse au journal Simulation situation en Italie. Évalué à 5.
Ces taux de mortalité viennent des études scientifiques. Par exemple, cette étude publiée chez Nature avance 1,4% : https://www.nature.com/articles/s41591-020-0822-7.
On n'a pas de mesure très précise mais on commence quand même à avoir une idée de l'ordre de grandeur. Il y a eu des cas où on a testé toute la population après une vague d'épidémie (paquebot de croisière mis en quarantaine, quelques petites villes italiennes pour lesquelles la vague est passée). L'ordre de grandeur, c'est environ 50% des contaminés ne vont pas développer de symptômes (et 50% des contaminations par une personne qui va développer des symptômes se fait avant l'apparition des symptômes => 75% des contaminations se fait par une personne qui ne présente pas de symptôme). Quand je parle de 50%, ça sera peut-être 30% ou 70%, mais en tout cas, ça paraît très peu probable qu'il y ait dix fois plus de contaminés sans symptômes.
La forme de la courbe dépend de R0, qui dépend des mesures de confinement. Et la courbe du nombre de malades ne dépend pas du nombre de lits. Le nombre de morts, par contre, dépend du nombre de malades et du nombre de lits. Et c'est très important de respecter les mesures de précaution pour limiter le nombre de malades, et surtout éviter de surcharger les hôpitaux.
On est encore très très loin d'avoir 20% de la population infectée.
[^] # Re: modèle
Posté par Bruno Michel (site web personnel) . En réponse au journal Simulation situation en Italie. Évalué à 7.
NON, les mesures de confinement, même prises trop tard comme en Italie, ont des effets très importants pour limiter le nombre de malades et surtout le nombre de morts.
On est autour d'un taux de mortalité de 1% pour les malades tant que les hôpitaux ne sont pas débordés, et de 5% ensuite. C'est énorme et on voit l'importance de ne pas surcharger les hôpitaux. Les mesures de confinement sont super importantes pour ça. J'encourage tout le monde à suivre au mieux les recommandations des scientifiques sur les mesures de distanciation sociale.
[^] # Re: Comment accéder à ses données
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Des nouvelles de Cozy. Évalué à 4.
Je ne pense pas qu'un logiciel « weboob as an API » mettrait B-I sur la paille. Ça peut convenir pour des auto-hébergés, mais c'est loin d'être suffisant pour proposer ce service à une échelle plus vaste. B-I utilise un mélange de récupération des données via les API DSP2 et du scraping. Pour la partie DSP2, il y a des contraintes légales et financières pas évidentes. Pour le scraping, il faut faire attention à ne pas se faire blacklister les adresses IP. B-I utilise également des fermes de simulateurs android avec les apps mobiles des banques pour scrapper certaines données, et c'est pas weboob qui est utilisé dans ce cas.
Je suis d'accord : si Cozy ne doit servir que d'agrégateur bancaire, sa valeur est faible. La force de Cozy est dans sa diversité, dans sa capacité à avoir des connecteurs pour importer des factures, la synchro des photos, la prise de notes, etc.
# Attention
Posté par Bruno Michel (site web personnel) . En réponse au journal Confinement Covid-19 et attestations, mise à jour. Évalué à 8.
Attention, cet article de numerama indique que le gouvernement a rétropédalé et les attestations numériques ne sont plus valables : https://www.numerama.com/tech/612262-attestation-de-deplacement-sur-smartphone-le-gouvernement-retropedale-seul-le-papier-est-valable.html
[^] # Re: Toner de toner
Posté par Bruno Michel (site web personnel) . En réponse au journal Confinement Covid-19 et attestations, mise à jour. Évalué à 7.
Oui, mais il y aurait une exception si c'est pour le travail.
Non, on ne peut pas raturer la date.
J'aurais tendance à dire que oui pour être plus prudent.
Oui, c'est une par personne.
[^] # Re: montée en charge : Mattermost / reverse-proxy Apache
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Vie dématérialisée. Évalué à 9.
Bearstech a publié récemment un article sur ce sujet : https://bearstech.com/societe/blog/trouver-la-configuration-optimale-dApache-bonnes-pratiques-et-analyses/
[^] # Re: Comment accéder à ses données
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Des nouvelles de Cozy. Évalué à 4.
Pour la question joker, le contexte n'est pas très favorable et ce n'est pas là que l'on veut mettre la priorité.
La directive européenne DSP2 qui devait aider les gens à avoir plus facilement accès à leurs données a été retournée par les banques : elles sont très en retard pour proposer les API, mais elles ont déjà mises en place de l'authentification à 2 facteurs, avec des règles contraignantes pour nous. Pour le moment, même en passant par B-I, c'est compliqué, on a pas mal d'erreurs. Du coup, on est plutôt dans une position d'attente, en espérant que la situation s'améliore du côté des banques.
Ensuite, weboob n'est pas si simple à intégrer avec Cozy et ne permet pas de faire tout ce que l'on fait. Il manque par exemple la catégorisation bancaire. On a commencé à travaillé sur le sujet de la catégorisation bancaire (indépendamment de la source des données) dans l'espoir que des contributeurs s'attaquent à la partie connecteurs.
Enfin, on a peu d'auto-hébergés et peu de contributions, ce qui ne nous encourage vraiment pas à faire du spécifique pour les auto-hébergés. On préfère que nos développements profitent à plus de monde. On a sorti l'application notes et le gestionnaire de mots de passe, qui peuvent être utilisés aussi bien par les auto-hébergés que pour les instances chez Cozy Cloud.
[^] # Re: Multi utilisateur
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Des nouvelles de Cozy. Évalué à 5.
Qu'appelles-tu multi-utilisateur ? Une installation de Cozy sur un serveur peut servir pour plusieurs utilisateurs. Chaque utilisateur a alors son instance, avec son nom de domaine, et peut partager des répertoires et documents avec d'autres utilisateurs.
Pour un contexte en entreprise où l'on veut avoir des groupes d'utilisateurs, avec du LDAP, des règles pour donner des permissions, et des notions de rôles pour certains utilisateurs, Cozy est effectivement mal adapté. Et je conseille plutôt NextCloud pour ce cas d'usage. On reste une petite équipe et on ne peut pas tout faire, et sur ce terrain, NextCloud a trop d'avance pour que ça fasse sens de lutter.
Chez Cozy, on reste plutôt centré sur une approche où chaque utilisateur est maître de ses données et va pouvoir regrouper dans un seul espace des données provenant de plusieurs contextes, dont potentiellement un contexte professionnel. On peut toucher des entreprises, mais c'est via d'autres angles : l'objectif est plutôt d'équiper les clients de ses entreprises avec un Cozy que les salariés.
[^] # Re: Comment accéder à ses données
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Des nouvelles de Cozy. Évalué à 6.
Si tu veux exporter les données, tu peux aller sur ton Cozy, puis dans l'application « Settings ». Il y a un bouton pour télécharger tes données (ça va t'envoyer un mail avec un lien vers une page où tu pourras télécharger tes données, généralement en plusieurs archives zip pour éviter d'avoir une très grosse archive dont le téléchargement prendrait plusieurs jours et qu'il faudrait reprendre depuis zéro si ça plante). Ça sera du JSON et pas du CSV pour les données extraites de la base de données.
Si tu préfères des API, on a ce qu'il faut. En fait, toutes les opérations que font les applications et connecteurs passent par des API. Pour la partie authentification et contrôle d'accès, tu peux passer par un client OAuth2. Et je pense que tu vas surtout être intéressé par les API du Data System, qui reprennent les API de notre moteur de base de données (CouchDB). Et les données bancaires ont un formalise décrit sur https://docs.cozy.io/en/cozy-doctypes/docs/io.cozy.bank/.
[^] # Re: Intérêt du modèle client/serveur ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Bitwarden, un gestionnaire de mots de passe libre. Évalué à 2.
Je confirme, c'est l'idée. C'est bien entendu plus compliqué que ça (FsWatcher, l'équivalent de inotify pour macOS n'a pas d'événements pour les close par exemple), mais en gros, ça revient à écouter les changements sur une partie de l’arborescence, et quand un fichier change, on attend un peu après les derniers changements, puis on va lire progressivement le fichier et envoyer ça au serveur.
En général, la plupart des logiciels gardent les documents des utilisateurs ouverts (au sens avec un file handler) pendant des périodes de temps très courtes. Au moment où ils font la sauvegarde, ils ouvrent le fichier, écrivent, puis referment le fichier. Pas mal de logiciels passent par un fichier temporaire : ils ouvrent un fichier temporaire, écrivent dedans, le referme, puis déplace ensuite le fichier temporaire au-dessus de l'ancienne version.
Encore une fois, c'est l'idée générale. En vrai, c'est plus compliqué que ça. Je recommande la lecture de https://danluu.com/deconstruct-files/ pour ceux qui veulent creuser le sujet.
Ils pourraient, mais, à ma connaissance, ce n'est pas comme ça qu'ils fonctionnent. Ils ont un mode de fonctionnement qui ressemble plutôt à une base de données, mais sans la même qualité d'implémentation. Le fichier est ouvert en permanence pendant que le logiciel tourne, souvent avec un second fichier qui sert de verrou (« lock-file »). Les écritures ne se font pas séquentiellement du début vers la fin, mais en sautant d'un endroit à un autre. Ils n'ont pas de journal d'écriture qui permet de repartir en cas de problème. Ils pourraient utiliser sqlite3 plutôt que le format de fichiers kdbx… mais ils ne le font pas.
J'avais creusé la question pour le client desktop de Cozy et j'étais tombé sur beaucoup de messages dans des forums de personnes qui avaient perdu leur base de mots de passe keepass à cause de ce genre de problème. Ce n'est pas qu'un problème théorique. Après, c'est aussi possible que ça reste très rare et que mon avis soit biaisé parce que j'ai justement creusé les forums pour aller chercher ce genre de problèmes.
[^] # Re: Intérêt du modèle client/serveur ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Bitwarden, un gestionnaire de mots de passe libre. Évalué à 10.
Je ne prétends pas être un expert et je ne connais que de nom KeepassXC, mais de ce que j'en comprends, il y a deux modes de synchronisation : soit l'utilisateur fait manuellement une action pour synchroniser ses mots de passe, soit ça se fait automatiquement.
Si c'est manuel, ça marche bien mais c'est vite chiant.
Si c'est automatique, il faut faire attention à ne pas corrompre la base de données. En mode client/serveur, le serveur garantit ça. Si c'est de la synchronisation via Dropbox, NextCloud ou un autre outil de synchronisation de fichiers, il peut arriver qu'une écriture de l'outil de gestion de mots de passe arrive au même moment qu'une synchronisation et que la base de données se retrouve ainsi corrompue. Ou qu'un fichier de lock soit synchronisé et empêche d'utiliser son gestionnaire de mots de passe sur un ordinateur parce qu'il est ouvert sur un autre.
Par exemple, keepass propose une manière que je trouve assez compliquée de faire de la synchro automatique : https://keepass.info/help/kb/trigger_examples.html#dbsync.
J'aurais tendance à dire que pour un geek, l'approche keepass/keepassxc est séduisante. Pour le commun des mortels, passer par un client/serveur est plus simple.
Il y a ensuite la question de s'auto-héberger ou non. Tu dis que ce n'est pas à la portée de tout le monde. Je suis bien d'accord. Mais avoir un serveur NextCloud et faire des sauvegardes régulières ne l'est pas non plus. Ça me semble être grosso modo le même niveau de difficultés dans les deux cas. J'entends que le serveur NextCloud peut servir à d'autres choses et que, quitte à s'embêter, autant que ce soit le plus utile possible.
Quand à passer par une clé usb, un disque dur ou du samba, j'ai du mal à voir comment faire ça et avoir son trousseau de clés à jour sur son smartphone, ce qui reste un usage très important des gestionnaires de mots de passe (peut-être en partie parce que c'est plus compliqué de taper un mot de passe sur un smartphone que sur un clavier physique).
[^] # Re: Implémentation dans Cozy Cloud
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Bitwarden, un gestionnaire de mots de passe libre. Évalué à 5.
Tout à fait, garder la compatibilité avec l'upstream (et faire remonter nos modifications upstream quand cela fait sens) est un objectif pour nous.
[^] # Re: Serveur libre ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Bitwarden, un gestionnaire de mots de passe libre. Évalué à 8.
Oui, l'implémentation officielle s'appuie sur Microsoft SQL Server. C'est pourquoi je conseille aux personnes qui veulent s'auto-héberger de plutôt utiliser la version en Rust, qui elle, est compatible avec sqlite, MySQL et PostgreSQL (de mémoire).
[^] # Re: Serveur libre ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Bitwarden, un gestionnaire de mots de passe libre. Évalué à 3.
Oui, je confirme : l'implémentation officielle du serveur est bien sous licence libre.
[^] # Re: Implémentation dans Cozy Cloud
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Bitwarden, un gestionnaire de mots de passe libre. Évalué à 10. Dernière modification le 07 mars 2020 à 16:44.
Haha, je suis grillé :)
Oui, j'ai réimplémenté la partie serveur de bitwarden dans Cozy. On peut utiliser les clients officiels de Bitwarden avec, mais c'est un peu compliqué de trouver comment se connecter (il faut passer par des options avancées pour saisir l'URL du serveur Cozy). C'est pourquoi, on travaille aussi sur des clients Cozy : ce sont des forks des clients officiels, avec quelques modifications d'interface, notamment pour simplifier la connexion. On propose également des passerelles entre le trousseau de clefs bitwarden et les comptes utilisés pour les connecteurs.
Tout n'est pas encore fini, mais c'est déjà utilisable. Vous pouvez installer l'app Cozy Pass sur votre instance Cozy pour vous lancer !
[^] # Re: Petits ajouts
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Bitwarden, un gestionnaire de mots de passe libre. Évalué à 7.
Pour ceux qui préfèrent le Ruby, il y a un début d'implémentation de client ici : https://github.com/edas/bitwapi.
[^] # Re: Si je comprends bien…
Posté par Bruno Michel (site web personnel) . En réponse au journal Des virus, des hommes, et de la dynamique.. Évalué à 5.
Oui, le pourcentage de chances d'être hospitalisé est plus important pour déterminer si le système de santé peut faire face à la situation. Mais, ici aussi, je me demande d'où sort le 20%. Pour moi, ça devrait être 8% : jusqu'ici, on parlait de 80% des contaminés sont des malades avec des symptômes, et 10% des malades avec symptômes nécessitent une hospitalisation.
[^] # Re: Si je comprends bien…
Posté par Bruno Michel (site web personnel) . En réponse au journal Des virus, des hommes, et de la dynamique.. Évalué à 4.
D'où vient ce pourcentage ? Il me semblait que, dans le précédent journal, on parlait de 20% de porteurs sains, donc 80% de chances de développer des symptômes.
[^] # Re: Porteurs sains
Posté par Bruno Michel (site web personnel) . En réponse au journal Des virus et des hommes. Évalué à 7.
Tout à fait, on parle bien d'une diminution.
Je pense que la confusion vient du mot « cas », dont le sens n'est pas le même selon que l'on inclut ou non les porteurs sains dedans.
Le billet explique qu'on va atteindre un certain nombre de personnes touchées par le virus au moment du pic qui dépend de R0. On suppose que l'évaluation de R0 ne change pas si on détecte des porteurs sains (ça a l'air d'être l'hypothèse prise par le billet, mais j'aurais bien aimé la voir détaillée). On peut donc dire que l'on aura n personnes touchées par le virus au moment du pic.
On sait également que 10% des personnes ayant des symptômes vont être des cas graves, et 2% des personnes ayant des symptômes vont mourir.
S'il n'y a pas de porteurs sains, il y a 100% des n personnes qui vont avoir des symptômes, 10% des n personnes qui vont être des cas graves et 2% des n personnes qui vont mourir.
S'il y a 20% de porteurs sains parmi les n personnes, ça ne fait plus que 80% des n personnes qui vont avoir des symptômes. On a bien multiplié par 0,8 le nombre de cas (personnes avec des symptômes). De même, il n'y aura que 10% des personnes avec symptômes qui vont devenir un cas grave, soit 10% des 80% des n personnes => 8% des n personnes. Et 2% des personnes avec symptômes, soit 2% * 0,8 = 1,6% des n personnes qui vont mourir.
Est-ce plus clair ?
# Les contributions sont les bienvenues
Posté par Bruno Michel (site web personnel) . En réponse au journal Tenter une première modification sur le code de LinuxFr.org. Évalué à 10.
Salut, je suis le développeur principal de la version Ruby on Rails du site. Ces dernières 4 ou 5 années, je ne suis plus très actif (mon dernier commit remonte à 6 mois par exemple), donc c'est vraiment bienvenu que d'autres personnes s'intéressent au code et proposent des PR.
Le gros du code a été écrit en 2009 et 2012. Ça remonte pas mal et certaines choses ont mal vieillies (mais moins que ce que l'on pourrait craindre). Dans l'ensemble, Ruby on Rails fait du bon boulot et le code est dans un état correct. Il y a des parties qui ont été écrites avant que Ruby on Rails ne propose une solution à ça, et si on réécrivait ça aujourd'hui, ça serait beaucoup plus simple en utilisant la solution de Ruby on Rails (par exemple, on n'utilise pas ActiveJob pour les jobs de publication des news sur twitter). Mais pour les parties qui ont mal vieillies, je pense plutôt à la doc et aux tests (ou plutôt l'absence de tests).
Non, il n'y en a plus. Il y en a eu par le passé, mais sans intégration continue et avec une couverture loin d'être suffisante. Du coup, ils ne servaient pas à grand chose, et quand ils ont cassé sur des mises à jour de Ruby on Rails ou d'autres gems, la solution la plus simple a été de retirer les tests cassés. À la fin, j'ai fini par tous les retirer.
Pas vraiment (ou des trucs trop anciens pour être vraiment utiles), mais j'essaye de répondre aux questions que l'on me pose.
Oui, c'est possible (surtout s'il n'y a pas de commentaires avec un avis négatif dessus). C'est probablement préférable d'indiquer dans l'entrée de suivi que tu comptes proposer une PR. Globalement, on a plutôt tendance dans l'équipe à accepter facilement les contributions.
Je dirais que le suivi est ce qui s'en rapproche le plus. Il y a eu une liste de diffusion par mails pour ça, mais je crois qu'elle n'existe plus.
Une pull request suffit pour ça.
Dans le fichier
config/database.yml, il y a une sectiondevelopmentqu'il faut modifier en :[^] # Re: Et la version courte ?
Posté par Bruno Michel (site web personnel) . En réponse au journal Exercices de programmation et benchmarks. Évalué à 6.
Une version possible en Ruby :
[^] # Re: J'aurai aimé...
Posté par Bruno Michel (site web personnel) . En réponse au journal Appel des travailleuses et travailleurs du numérique pour une autre réforme des retraites. Évalué à 8.
Oui, mais la simplification est un moyen, mais une fin en soi. Sinon, il suffirait juste de supprimer complètement les retraites, difficile de faire plus simple !
Le gus essaye de simplifier, mais au passage, il casse des acquis sociaux. Pour la réforme des retraites, repousser l'âge à 64 ans quand on sait que le taux de chômage est élevé chez les personnes qui ont plus de 60 ans, ça va mettre des personnes dans la précarité.
Pour prendre une analogie, pour le code, on aime bien aussi la simplicité. Mais si quelqu'un arrive avec une demande de changements qui simplifie le code mais qui casse des tests unitaires, ça ne va pas être accepté.
Après, je ne dis pas, il y a aussi des gens qui ont eu des avantages qui ne paraissent plus légitimes aujourd'hui et qui ne veulent pas les lâcher. Mais je ne pense pas que ce soit la principale raison de l'opposition à la réforme des retraites.
Mwais, on nous a déjà vendu ça à la dernière réforme des retraites et l'espérance de vie en France n'augmente vraiment pas très vite ces dernières années. Mais surtout, si on veut parler espérance de vie, il faudrait attaquer vraiment le sujet et pas juste de manière superficielle : il y a un très grand écart sur l'espérance de vie entre les cadres et les ouvriers. Est-ce que cela ne devrait pas se refléter dans l'âge de départ à la retraite (ou l'âge pivot) ?
[^] # Re: J'aurai aimé...
Posté par Bruno Michel (site web personnel) . En réponse au journal Appel des travailleuses et travailleurs du numérique pour une autre réforme des retraites. Évalué à 7.
Je maintiens que les erreurs de bonne foi ne rentrent pas dans le cadre de la fraude fiscale, et que faire un erreur en bonne foi ne fait pas de toi un fraudeur.
La notion d'écart fiscal recouvre 2 types d'irrégularités :
Effectivement, l'état aurait dû percevoir des prélèvements qu'il n'a pas perçus à la fois pour la fraude fiscale et les erreurs involontaires.
Je trouve le diagramme de cette page assez clair. Il y a d'ailleurs une case rouge avec marqué dedans « Irrégularités volontaires » et libellé comme « Fraude ». Les « Irrégularités involontaires » sont dans une autre case.
Je plaide coupable pour avoir entretenu la confusion : les montants des redressements sont effectivement pour la fraude et les erreurs involontaires. J'ai mis en avant ces chiffres car le rapport ne fournit pas de chiffres séparés pour les deux (en gros, ils disent que ce serait bien d'avoir les chiffres séparés mais que l'état n'a pas mis en place ce qu'il faut pour pouvoir les calculer).
Je parle effectivement de lutte contre la fraude fiscale, car elle me paraît plus importante et être une mesure plus juste aux yeux du plus grand nombre de citoyens français. Mais, à titre personnel, je serais très content si l'état français est capable de recouvrer plus d'argent sur les erreurs involontaires.
[^] # Re: Et dire que...
Posté par Bruno Michel (site web personnel) . En réponse au journal Appel des travailleuses et travailleurs du numérique pour une autre réforme des retraites. Évalué à 10. Dernière modification le 11 décembre 2019 à 09:59.
Moi, ça m'est arrivé. L'agence immobilière m'a demandé l'équivalent d'un mois de loyer (pour un studio) sur la caution. C'était très clairement abusif au vu des états des lieux entrants et sortants, et quand j'en ai discuté avec eux, ils m'ont proposé une réduction de 50€, puis de 100€. J'étais toujours fâché, et j'ai saisi la commission départementale de conciliation. Devant cette commission, ils ont accepté de me rendre les 2/3 de ce qu'ils avaient gardé de la caution. Je pense que si j'avais été devant la justice, j'aurais encore pu récupérer une centaine d'euros supplémentaires (mais ça m'aurait probablement coûté autant en frais et ça aurait pris longtemps).
[^] # Re: J'aurai aimé...
Posté par Bruno Michel (site web personnel) . En réponse au journal Appel des travailleuses et travailleurs du numérique pour une autre réforme des retraites. Évalué à 10.
Le rapport dit très précisément le contraire : l'erreur de bonne foi existe, mais elle ne rentre pas dans la case « fraude fiscale ». Le rapport parle d'écart fiscal pour la somme de la fraude fiscale et des erreurs de bonne foi. On trouve également l'optimisation fiscale, qui est un ensemble de pratiques légales pour réduire les prélèvements fiscaux. Et s'il y a une limite qui est floue, c'est plutôt entre fraude fiscale et optimisation fiscale (toujours selon le rapport), car cela fait souvent intervenir des règles très complexes et cela joue beaucoup sur l'interprétation des lois.
C'est un autre débat, mais je suis d'accord, notre système fiscal mériterait d'être plus simple : moins de niches fiscales et de cas particuliers, et des règles plus compréhensibles et accompagnées d'exemples pour les cas plus généraux.
De ce que tu as décris, ça n'a pas l'air d'être le cas. Enfin, sauf si tu nous dis que tu as monté 3 sociétés dans un paradis fiscal, que tu as un compte en Suisse dont le FISC n'est pas au courant et que ton jet privé de fonction te sert à aller tous les week-ends à Ibiza. Ou encore, que tu vends plein de trucs sur Amazon sans payer la TVA.
Oui, c'est également mon avis. D'ailleurs, les études montrent que le taux effectif de prélèvement des impôts est plus bas pour les très riches que pour les tranches moyennes et qu'un des mécanismes qui permet d'y arriver est justement la possibilité qu'ils ont d'employer des fiscalistes pour profiter de cette complexité (je parle ici d'optimisation fiscale, la partie légale, mais la fraude n'est pas toujours très loin).