Glandos a écrit 1345 commentaires

Disons qu'en C ou C++, atteindre plus d'une vingtaine de dépendances, c'est vraiment pas souvent. C'est vrai que c'est peut-être un frein au développement. Mais ça rend les choses un peu plus claires aussi.

En bref : ça manque d'outil d'analyse de dépendances ;)

C'est tellement idiomatique et facile qu'il y a certaines dépendances qui n'ajoutent qu'une petite fonction ou macro utilitaire.

Oui, ça je comprends que ça ressemble à NPM. Mais ça m'inquiète en fait. Et c'est assez bien analysé par Lars Wirzenius.

Donc est-ce que mes craintes sont fondées ? Est-ce qu'on va finir avec des applications à moitié libres, parce que l'autre moitié sera composée de centaines de dépendances aux licences incompatibles ou au code source manquant ?

Ça ressemble à un troll, mais j'aime énormément le concept de Rust, et je n'aimerais pas que son écosystème me dissuade de l'utiliser :(

C'est ça, c'est un cache. Un cache qui n'écrit que toutes les heures.

Alors, je pourrais faire une partition dédiée, mais il me faudrait réduire l'existante, m'assurer qu'il y aura assez de place sur la nouvelle, c'est du boulot et ça manque de dynamisme.

Mais disons que c'est une solution : je serais très curieux de voir les paramètres d'un ordonnanceur qui fait la même chose. Allez, sans la compression.

Ah pardon, j'ai mélangé les Tio et les To. Bon, ça fait 3894 jours, soit un peu plus de 10 ans et demi. Ça ne change rien à la remarque, bien évidemment.

http://downloadcenter.samsung.com/content/UM/201711/20171115103115156/Samsung_SSD_850_PRO_Data_Sheet_Rev_3.pdf

J'ai un 256 Go, donc prévu pour 150 To d'écriture. Après 155 jours, si j'ai fait 5,43 Tio, ça me fait 4281 jours, soit un peu moins de 11 ans.

Bon.

Certes.

Et alors ?

Ceci étant dit, merci quand même de me faire faire les calculs de base. J'aurais sûrement l'air bête, mais au moins, ça servira peut-être aux autres.

EDIT: Ah ben en fait, j'ai pu éditer les tags moi-même.

Bon, la syntaxe change d'un système à l'autre, désolé. C'était plutôt :

collectd carbon graphite anything-sync-daemon zram

Merci au modérateur l'enlever le premier tag, complètement inutile.

Intéressant. C'est supporté par RedHat je vois.

Et pourquoi Zanata ? Weblate et Pootle sont assez connus. Pootle a même assez bien participé, car il me semble que certaines bibliothèques créées pour lui ont été utilisé ailleurs. Mais peut-être que Zanata apporte quelque chose que je n'ai pas su voir ;)

Je ne comprends pas les implications. Enfin, JavaScript vers JSON, oui, mais Python vers YAML, non.

Python a un module json dans sa bibliothèque standard. Mais pas de YAML. Donc bon, c'est pas évident comme lien.

J'ai fini par faire ça aussi.
Et un accès de secours avec Shell in a box. Sur une URL en HTTPS, avec un sous-chemin non indexé.
Il est possible aussi de faire écouter le serveur SSH sur un port secondaire.

Question de goût.
Perso, quand j'écris des playbooks ansible, c'est toujours la misère, parce qu'il y a une espace en trop (ou en moins), et ce n'est plus une liste, c'est un dictionnaire, ou l'inverse.
C'est sûrement un problème qui vient de moi, mais perso, JSON, je trouve que c'est plus « sympa ».

Sans troller, y a-t-il des meilleurs arguments ?

Ah. Sourceforge. Y a-t-il une bonne raison, autre que historique ?

Évidemment, la centralisation de tout le code sur GitHub est un souci, mais il y a des alternatives :
- BitBucket
- GitLab
- FramaGit

C'est surtout que SourceForge a une interface vraiment pas top. OK, je viens, grâce à OpenJardin, de voir qu'ils ont totalement rafraîchi l'interface, mais ça reste quand même en deçà des standards.

Le SVG, c'est la vie. Enfin, non pas tout le temps, mais dans le cadre d'un logiciel avec affichage potentiellement dynamique, il faudrait l'utiliser.

Actuellement, boobank a une commande d'export vers Budgea.
C'est pratique, parce que ça permet d'avoir boobank sur un autre ordinateur, de confiance. Peut-être est-il possible de faire pareil pour Cozy ? C'est une simple suggestion, je ne connais pas les plans en interne :)

https://docs.nextcloud.com/server/12/admin_manual/configuration_files/external_storage_configuration_gui.html

Mon répertoire data est plutôt vide. Il ne contient que quelques documents synchronisés pour des raisons pratiques.

Ne plus stocker les fichiers dans CouchBD (pour simplifier les sauvegardes et savoir retrouver les fichiers en cas de corruption de la base CouchDB). Les fichiers ne sont plus stockés dans CouchDB. Sur notre infrastructure, ils sont stockés dans Swift. Pour les auto-hébergés, ils sont stockés dans un répertoire du disque dur local (attention, il ne faut pas modifier directement ce répertoire). On aimerait ajouter d'autres modes de stockage, minio en particulier.

J'aimerais partager mon expérience avec Nextcloud sur ce point. J'ai mes fichiers photos, films, et musique sur mon NAS, accessibles en NFS sur mon ordinateur à la maison. Donc performant. Nextcloud, installer sur le même serveur me permet d'accéder aux fichiers locaux en créant des « points de montage », façon UNIX. C'est très efficace, et ça évite la redondance d'informations. Évidemment, ça demande à Nextcloud d'avoir une routine un peu complexe de scan de nouveaux fichiers et de mise en cache des index.

Cela a-t-il été envisagé pour Cozy ?

Sinon, c'est un beau logiciel. Pour l'instant, il en fait peut-être moins que les autres, mais il a l'air de le faire bien. C'est chouette.

Euh, c'est Edge Funds ou Hedge Funds ? Le premier n'a pas l'air d'exister pour moi.

Ils sont en .Net Core2 avec Docker

Lol. J'ai un Intel Atom D2550 en auto-hébergement. Avec 4 Go de RAM. Docker, c'est pas envisageable, même en mettant de côté tous les autres défauts. Oui, c'est un peu un troll, mais je continuerai pas ici quand même.

Et d'après le site, un autre pré-requis est SQL Server 2017. Donc non, c'est pas possible, même si c'est docker-isé, de faire tourner ça sur ma machine, pour le côté propriétaire de la chose.

Un grand merci vers le serveur Bitwarden en ruby. La version officielle est en C#, donc vraiment dure à mettre sous GNU/Linux. En ruby, bon, ça va déjà mieux. J'aime pas trop ruby, c'est une question de goût, mais ça tourne quand même ;)

Tiens. Merci beaucoup d'avoir amené les jumeaux monozygotes sur la table du débat des marqueurs biométriques. On les avait oubliés. C'est peut-être la même chose qui nous fait oublier les différents handicaps lorsqu'on parle d'accessibilité, mais là, c'est encore plus marrant, parce que la biométrie marche vraiment rarement avec cette particularité.

Je pense que personne n'a jamais demandé qu'il y ait quoi que ce soit de secret. Ce qu'on veut, c'est être sûr que la personne qui accède au service soit la même que celle qui a créé le compte.

OK, j'abandonne par KO au nombre de réponses. On ne se convaincra pas mutuellement. Allez, juste une dernière.

Comment être sûr que c'est la même personne ? En lui demandant quelque chose qu'elle a inventé. Et pas quelque chose qu'elle n'a pas choisi, comme ses empreintes digitales. Car la biométrie pose également le problème de l'identification (justement) : en admettant que le lecteur ne transmette qu'une version non réversible de l'identificateur biométrique choisi, une fois qu'on le possède, on peut accéder à TOUS les services, sans distinction. Et identifier la personne sur TOUS les services.

La procédure d'accès en cas de décès, en cas de perte fait forcément intervenir un facteur humain. Une machine ne sait pas le faire. C'est un gros défaut de l'informatique d'aujourd'hui, et la biométrie ne le résoudra pas. Parce que si je meurs noyé dans un accident d'avion, personne ne va aller chercher ma main ou ma tête pour déverrouiller mon compte. On a la même problématique qu'avec les mots de passe.

Fiabilité : qui n'a pas perdu un vieux mdp pour accéder à une archive ou à un ordinateur? (ex: mot de passe du BIOS), avec à la clé des pertes de données ou d'argent? (mdp d'un portefeuille BitCoin?).

C'est exactement ce que je demande à un mot de passe. Si le l'ai perdu, c'est tant pis.

Coût : Pour une entreprise, quel est le coût de l'identification par mot de passe (éventuellement, récupération des mdp perdus, stockage au coffre fort, temps perdu par tout ça, etc).
Le coût sera le même quel que soit la méthode d'authentification, puisqu'il faut stocker un secret côté serveur. Le coût de récupération est autrement plus élevé quand il s'agit d'autre chose que d'un mot de passe puisque ça nécessite des étapes supplémentaire (envoi d'un jeton physique, vérification de l'identité par un humain, …).

Ergonomie : on impose à l'utilisateur une démarche d'identification qui prend un certain temps et qui occuppe son cerveau pendant de précieuses secondes. La démarche n'a rien de naturel, elle demande d'inventer et de mémoriser des mots de passes, éventuellement complexes, de les changer régulièrement, etc.

Gestionnaire de mots de passe. Gestionnaire de mots de passe. Gestionnaire de mots de passe.

Sécurité : utiliser un mdp faible ou un protocole trouvé met en danger les données qu'on manipule. Utiliser un mdp fort et un protocole non-trouvé met en danger la confidentialité future des données, puisqu'il est probable que dans un avenir plus ou moins proche, la puissance de calcul ou des failles découvertes permettront d'accéder au contenu.

Une dernière pour la route : gestionnaire de mots de passe.

Oui, je l'ai mis dans le dépôt après avoir utilisé ssl-cert-check.
Je n'aime pas tomber sur des dépôts en jachère sans savoir quoi utiliser, donc j'essaie d'être poli avec les autres. Et ne pas supprimer le dépôt non plus, vu que je l'ai annoncé publiquement.

Mais je suis passé à ssl-cert-check. Ça couvre parfaitement mon besoin. C'est en bash (bof), ça forke de partout (bof, mais en shell, on fait pas autrement), ça dépend de openssl (bof aussi, mais ça gère le starttls de base), mais c'est lisible et le développement est actif.

Ça, ça a l'air d'être le genre de script que j'aurais bien écrit.

Bon, c'est en bash, mais en bash lisible.

Vu que l'implémentation en CoffeeScript est différente, est-il possible de s'en servir va scorepw ?
Je sais que c'est pas évident… Foutre du JS dans un programme C, quel dommage ;)

Mais ça va finir par arriver si d'autres bibliothèques d'évaluation de la qualité des mots de passe arrivent.

Merci beaucoup :)

Au moins, ça sera dispo pour les autres.