Alex G. a écrit 649 commentaires

Le serveur d'Open Food Facts est en perl :-)
https://github.com/openfoodfacts/openfoodfacts-server/

La différence quand même c'est que tu peux auditer le code du client Signal, et voir par exemple que ta clé privé reste sur ton téléphone. Sur whatsapp tu n'as aucune garantie qu'il n'ont pas ta clé privée…

Comme on pouvait s'y attendre j'ai eu une fin de non recevoir: https://github.com/neo4j/neo4j/issues/12920#issuecomment-1226941038

Yes, cf le commentaire ci-dessus :-D

Quand j'ai regardé Arango j'ai eu l'impression que ce n'était pas très spécialisé graph mais que l'accent était plus mis sur le coté "document". Or dans mon cas il me semblait que c'était l'aspect graph qui était plus présent. (On y allait déjà à reculons de prendre un nouveau type de database sachant qu'on a déjà du mongodb, elasticsearch, postgresql…). Mais bon c'est sur c'était un choix un peu à l'intuition…

Maintenant on est un peu engagé avec du code Cypher (le language de Neo4j), mais oui à voir !

En fait tu as peut être raison et c'est cool de creuser.

Bon, pour le futur, car dans l'immédiat on est engagé avec du code historique (coté Perl) et un projet bien démarré (côté Python) !

Le problème du monde des ontologies est peut être la complexité perçue de l'extérieur (je m'y suis un peu intéressé déjà).
L'autre chose pour moi est qu'il me semble qu'on ne définit pas tant des concepts au niveau ontologiques (des classes de concepts) mais plus des instances (un catalogue).

Ce qui me fait dire ça:
1. on instancie des propriétés (par exemple le lien avec une instance de wikidata)
2. on a pas des relations différentes à décrire à chaque fois, c'est très simple on a juste la notion d'héritage, mais les propriétés, ce qui est définit etc se répète partout pareil.
3. si tu regardes bien tu verras qu'un des intérêt majeur pour nous est de traduire en plein de langue et de construire les "synonymes" (en les listant mais également grâce à une liste de synonymes généraux qui sont utilisés par inférence), je vois mal comment mettre ça simplement dans une ontologie.

À noter d'ailleurs que ce n'est pas une hiérarchie au sens "arbre" mais plutôt un Graphe orienté acyclique

Du coup, je ne vois bien qu'on pourrait définir une ontologie des composant d'une taxonomie (dire qu'il y a des synonymes, des parents, des propriétés) et définir la taxonomie comme un RDF, mais je ne vois pas bien ce que ça apporte ici (ça met juste un schéma sur ce qui existe, et ça n'apporte pas un fichier facile à éditer, alors que le format actuel est vraiment pensé pour une édition à la mano, donc compacte et assez facile à lire).

En tout cas je trouve ça intéressant et un premier pas pourrait être de montrer à quoi ça pourrait ressembler une petite taxonomy en mode ontologie et voir quels outils éventuels ça unlock. Tu viens contribuer :-D ?

Oh là là quelle bonne nouvelle !

On sait au moins qu'on a un backup :-)

C’est déjà complètement le cas avec la preuve de travail, concrètement.

Oui et en gros l'auteur dit que même en changeant le modèle, les blockchain on complètement échoué dans leur aspiration initiale (la décentralisation).

https://blog.dshr.org/2022/02/ee380-talk.html est un article hyper-intéressant.

Je l'avais lu il y a quelques temps et ce que j'en ai retenu (de mémoire), c'est que si le proof of stake (preuve de participation) règle le problème énergétique, il ne va pas changer un problème qui est pourtant celui qu'est censé résoudre la chaîne des bloques, celui du contrôle du réseau par très peu de monde…

Selon l'auteur c'est un des points faible du proof of stake, il va y avoir mécaniquement un effet d'accumulation sur quelques acteurs (ceux qui ont les moyens d'investir, de mobiliser de la monnaie en participation), ce qui est déjà un peu le cas avec la preuve de travail (où on a quelques grosses fermes car il y a des économies d'échelles). Bref on ne va pas favoriser un vrai participation "répartie".

Comme souvent en cryptographie ce n'est pas le cœur "théorique" de l'algorithme d'où vient le danger mais plus les contingences matérielles, ce qui vient autour (cf. par exemple les Attaque par canal auxiliaire).

Juste pour info, pour créer des connexions distantes et chiffrées entre machine, il y a aussi stunnel.org qui est pas mal (et dans l'esprit de tunnels ssh).

On peut le configurer avec des clés ssh, mais également avec un simple token partagé (psk). Voir ici: https://www.stunnel.org/auth.html

Malgré les réponses de CrEV (qui n'est clairement pas neutre, et c'est normal) je suis complètement de ton avis, et ça m'attriste. On voit clairement que Linux est le parent pauvre / n'est pas la cible des décideurs de chez Docker.

Ce ne sont pas les perfs qui me chagrinent si je mets docker dans une VM, c'est le fait que je dois réserver par avance la mémoire et l'espace disque… et ça vraiment, surtout pour la mémoire, c'est un grosse perte en pratique (docker a fait sa pub comme étant beaucoup plus rapide / flexible que les VM, c'est quand même marrant de le voir se justifier d'être dans une VM, même si c'est pour les développeurs…).

Bref j'ai l'impression que Docker n'a pas trop levé le petit doigt pour les développeurs sous Linux. Ça me chagrine, car je suis sûr qu'ils vont concentrer beaucoup d'effort sur la version desktop, qui en soit aurait été sympa à avoir, mais moi dans ces conditions, ce sera clairement non.

Moi j'ai bien aimé le projet pyinfra (sans l'avoir testé sur de gros projets).

C'est KISS là aussi, et perso mon expérience (plusieurs années) avec Ansible, m'a fait penser qu'à la fin c'est mieux de pouvoir programmer… (avec Ansible je me retrouvais souvent à utiliser les boucles, et des siouxeries de manipulation des variables, qui auraient été bien plus simple en python).

Je plussoie pour dire que Ansible se dit idempotent et souvent on lit que l'on décrit l'état plus que le processus, mais en pratique ce n'est pas vrai du tout. Quelques briques font effectivement ça, mais plein de brique ne le font pas du tout. Par exemple la suppression d'une ligne ajouté par un run précédent du programme n'est pas forcément géré (suivant la directive utilisé).

Je ne jette pas la pierre à Ansible, ça reste un outil correct, mais en pratique il faut tester les scripts ansible, tout comme le code, et Docker, avec son redémarrage de la feuille blanche à chaque fois, est plus prédictible (ce n'est toutefois pas le même scope que ansible, on est d'accord).

Perso je trouve ça juste. On parle de projets privés importants qui utilisent un produit "gratuit".

Je me rappelle il y a cinq ans, on avait discuté en équipe de passer sur gitlab.com (jusque là on avait un git self hosted) et j'avais proposé à l'équipe (et au patron) de payer, car ça semblait plus juste et que le prix était vraiment raisonnable, et ce même si on pouvait créer des projets "privés" gratuitement. C'était une question de soutenabilité. Et ça a fait facilement consensus. (la boite était aussi basé sur un modèle freemium, donc on savait bien ce que ça voulait dire !)

Ouais mais tu peux imaginer avoir fait des 1kg de plomb une grande feuille de quelque nano-mètres et du coup ça fait moins mal :-)

Te faire insulter, espèce de moule bigleuse ! ;-)

En effet, le calcul de l'éco-score reste un peu approximatif dans certains cas, car nous manquons parfois de données et devons utiliser le produit le plus proche de la base Agribalyse. Nous avons justement un projet en cours (pas loin de la publication) qui permet d'évaluer la recette pour essayer d'avoir un éco-score plus précis.

Mais dans le cas que tu pointes, c'est la catégorie qui n'était pas bonne: couscous préparés --> coucous à la viande. J'ai corrigé (mais on voit bien le travail de qualité que peut faire la communauté). On veut notamment faire des systèmes de règles pour corriger ce genre de problème. Genre : coucous préparés avec ingrédient viande --> couscous à la viande

Pour ce que le sujet intéresse, j'avais rapidement testé https://scuttlebutt.nz/ et trouvé ça très intéressant (le seul truc que je n'avais pas trouvé encore abouti était l'utilisation disque un peu haute, mais ça pourra s'améliorer).

L'idée est d'un réseau où chacun à sa chaînes de notes. De temps en temps on peut se connecter en allant au "café" (virtuel, où imaginons aussi un endroit) et synchroniser nos notes et du coup synchroniser aussi les flux de nos amis communs.

Dans un interview vidéo de veritasium à Bill Gates (lien youtube), il admet lui même qu'il a dit à Oxford de plutôt faire un partenariat avec une entreprise pharmaceutique plutôt que de donner la formule du vaccin. Et il se justifie en disant qu'un vaccin doit être réalisé par des laboratoires de confiance. (à chacun de juger…).

Il me semble que tu fais un jugement d'intention sur toute la ligne (sur mes intentions et sur leurs intention).

En quoi je suis "fan" des non libristes, au contraire, j'aimerais que la communeauté travaille à convaincre qu'il y a un chemin possible avec le libre.

il est interdit de faire du « à la demande »

C'est complètement faux ! La SSPL dit juste que si tu fais du « à la demande » tu dois publier le code qui te permet de le faire.

Pour moi ils tentent juste de maladroitement créer un équivalent de l'AGPL mais avec un scope un peu différent (et malheureusement plus difficile à définir).

Vraiment ça me rend triste de voir cette attitude de rejet totale de la démarche par beaucoup de libristes, au lieu de voir plutôt la problématique et de chercher une solution qui soit plus juste.

On peut reprocher à Mongo et Elastic de ne peut être pas avoir pris le temps de conserver la liberté des licences. Mais je trouve bizarre d'avoir des positions aussi peu nuancées à propos du choix de ces éditeurs (pour la discussion sur la licence en elle même il faut être plus clair en effet).

Pour moi Mongo et Elastic se défendent face à ce qui est proche du cas de la "tivolisation" qu'avait connu gnu/linux et qui a amené à la rédaction de la GPLv3 où le manque de liberté des utilisateurs des services en SAS et qui a amené l'AGPL.

Je suis d'accord que cette fois c'est peut être un peu moins la liberté des utilisateurs qui est menacée. Mais trouver un équilibre juste pour l'écosystème a toujours été, il me semble, un point important (Richard Stallman a toujours expliqué comment le copyright avait été introduit dans le contexte de l'imprimerie pour permettre aux éditeurs de vivre. Il rejetait sa généralisation aux logiciels, alors que les conditions ne sont pas les même, pas son principe initial. Il a toujours parlé d'équilibre).

Il me semble que la SSPL est une tentative (je redis maladroite) de faire en sorte qu'il y ai une "réciprocité". Elastic fournit un service facile de déploiement (même la planification des est intégré), et ce qu'ils demande avec la SSPL est la "réciprocité". Ils demandent que l'infrastructure de service (pas toute l'infra) soit opensource.

Ce que je veux dire, c'est que plutôt que de dénoncer seulement, je ne comprends pas pourquoi la FSF et l'OSI ne proposent pas plutôt de négocier pour trouver un moyen de régler ce problème avec une licence libre. On pourrait ainsi, d'ici un ou deux ans, retrouver des logiciels libre et rendre plus sain l'écosystème.

J'avais fait le même constat, mais j'ai lu (sans essayé) que la nouvelle version avait fait des progrès de ce côté là.

Mais tu ne crois pas que avoir un pied dans le monde des consoles permet de rester proche des éditeurs de jeu qui sont souvent des précurseurs de l'utilisation des CPU (et les joueurs conseillent souvent les gens autours d'eux sur le CPU à prendre pour leur PC), et donc un risque de perdre pied à long terme, au moins sur le marché grand publique ?

Oui son urologue est eugéniste ;-)