Glandos a écrit 1325 commentaires

Ça tombe parfaitement bien. Je vais bientôt passer en fibre, et je suis resté avec ma Freebox v5 en mode bridge. Je suis étonné par la surconsommation en fibre du serveur Mini.

Est-ce que la Freebox est configurée en mode bridge dans tous les cas ?

Lol : non. Enfin, pas vraiment. Le droit d'auteur est un concept très positif, mais dans son utilisation actuelle, il protège surtout les éditeurs (ou producteurs) contre les auteurs.

Les auteurs sont un peu mieux protégés en droit français qu'en droit anglo-saxon, grâces aux droits inaliénables en incessibles.

Mais 70 ans après la mort de l'artiste, ce n'est pas pour rémunérer l'artiste pour son travail. C'est pour assurer une rente aux détenteurs des droits commerciaux (qui eux, sont cessibles).

Certes. Ceci dit, si la bibliothèque apporte un vrai avantage, ça devrait suffire.

J'ai déjà dû regarder le code de Boost pour comprendre certaines choses. Ça donne vraiment pas envie de contribuer à Boost. Mais on continue de l'utiliser, et certaines personnes y contribuent, parce que ça leur apporte quelque chose.

Alors, j'ai exprimé en raccourci, mais pour moi, lisible à l'utilisation veut dire que l'API est lisible. Par contre, l'implémentation peut être un peu tarabiscotée. Le but est que la bibliothèque doit rendre la vie plus facile, et s'intégrer le plus possible avec l'utilisation de l'appelant, et pas l'inverse. C'est un long débat, j'ai un peu la flemme.

Y a-t-il une bonne raison de le mettre dans le namespace bits ? Ou bien c'est pour bien ranger le code ?

Sinon, oui, c'est pas lisible. M'enfin, le rôle d'une bonne bibliothèque, c'est d'être lisible à l'utilisation, pas à la lecture du code. D'où une bonne doc ;)

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.