srb a écrit 81 commentaires

Tout a fait: la libc est remplacée par musl, bash par ash et les outils GNU par busybox. Il existe des paquets pour remplacer le shell ou remplacer certains outils pour retrouver le fonctionnement habituel.
Cela en fait une distribution assez originale, pour le meilleur et le pire.

On utilise une surcouche maison (sheraf) sur ZODB qui fait un peu l'équivalent d'un ORM. Ajouter un attribut sur un objet se fait sans migration, en supprimer un pareil (mais dans ce cas les données restent en base jusqu'à la prochaine écriture de l'objet). Renommer un attribut peut aussi se faire sans migration en ajoutant un paramètre (mais une migration pour renommer l'attribut est évidemment possible). Évidemment, des migrations restent nécessaires si on veut découper un objet en deux, etc. Dans ce cas, il faut écrire un script Python, ce qui permet d'avoir accès à l'ensemble des attributs, méthodes sur les objets à transformer.

Je suis tout à fait d'accord sur la qualité des migrations SQL. Par contre, on a l'impression de perdre du temps à les faire. Notre pire cas d'usage est avec Django: certaines migrations sont inutiles car elles touchent des paramètres inutilisés en base, les migrations ne permettent pas l'utilisation des méthodes attachées aux objets. C'est plus lié à Django lui-même qu'à PostgreSQL, mais c'est une mauvaise expérience. On a aussi des cas avec Flask/SQLAlchemy qui sont plus agréables, sans soulever l'enthousiasme.

Peut-être que la conclusion sera que PostgreSQL reste le meilleur choix. Pour l'instant, on explore les pistes.

Est-ce que tu peux nous préciser en quoi PostgreSQL serait "rigide" ?

En utilisant des bases SQL, on se retrouve à faire des scripts de migration à chaque fois qu'on veut changer la structure de données. On en fait régulièrement, au fur et à mesure de la compréhension du métier.
Je connaissais l'existence du type JSON dans PostgreSQL mais je ne voyais pas trop l'intérêt si c'est pour tout sérialiser dans du JSON pour retrouver la souplesse et en sacrifiant l'intérêt d'une base relationnelle. Apparemment, c'est plus puissant que je ne pensais, je note ça comme élément à évaluer.

On utilise déjà PostgreSQL sur certains services que l'on maintient. On en est content tant que le service bouge peu (ou que c'est une exigence client).

Avec toutes les solutions NoSQL tellement nombreuses, est-ce que le risque n'est pas d'avoir à changer à nouveau par la suite ?

Oui c'est un risque. Faire le tour des solutions présentes est une tentative de minimiser le risque d'erreur plutôt que juste prendre la première qui passe, la plus populaire, etc.

Bien sûr, ce n'est pas une preuve absolue, mais c'est quand même plus solide qu'un ticket de caisse.

L'information contenue dans le NFT est simplement une URL. La chaîne ne contient pas l’œuvre achetée. Si le gestionnaire du domaine pointée par l'URL enlève ce qui est derrière le lien, comment prouver ce qui a été acheté ? Ou si le domaine disparaît?
L'encre d'un ticket de caisse s'efface avec le temps mais ça reste bien plus fiable.

Oui c'est archivé.

Il y a aussi plein d'autres dépôts nommé MS-DOS (probablement des forks pour la plupart).

Pour les curieux qui voudraient voir à quoi ça ressemble:
la page du manuel Sather sur les itérateurs

Le once est à la section 3.2.4. Lisez ce qu'il y a avant pour mieux comprendre.

Je ne suis pas habitué à ce type de syntaxe donc ça doit jouer sur le fait que je ne trouve pas ça très limpide.

Le choix de forcer l'usage des accolades dans Rust est d'éviter des bogues dus à l'ajout d'une nouvelle instruction à la suite de la première, sans se rendre compte que cette seconde instruction sera exécutée inconditionnellement car elle n'est pas entourée d'accolades (cf. une discussion sur rust-lang). Peut-être que c'est aussi la raison qui a guidé ce choix en Go ?

Avec l'outil de formatage automatique, l'erreur va être évidente au programmeur car la seconde instruction sera réindentée et donc ne semblera plus être dans un bloc qui n'existe pas. Dans ce cas, l'argument est moins convaincant.

Non, c'est vraiment un choix fait pour faciliter la vie des utilisateurs, au dépend des images ne contenant que des programmes libres. Cela a fait l'objet d'une résolution générale et d'un vote des Développeurs Debian : les différentes propositions et les résultats du vote

Le CD non officiel comportait les firmwares non-libres ; c'est ce que font maintenant les images officielles, donc l'installeur non officiel est devenu inutile.

Parmi les autres inconvénients (qui existaient en 2021, mais ont peut-être disparu depuis):

• la lenteur des compilations. Apparemment c'est lié aux allocations mémoires faites par musl qui sont moins efficace que celles faites par la glibc. C'est un problème connu, avec des pistes de solutions (mimalloc de microsoft). Source: tests dans un docker test compilation Python
• comparé à un système Debian, les mises à jour système sont extrêmement rapides (de mémoire, moins de 10 minutes). Par contre, il n'y a pas de vérification des configurations écrasées dans /etc ou de script de migration. Il est donc facile de se retrouver avec un système à réparer (et donc perdre bien plus de temps que le temps gagné lors de la migration).

Bref, si AlpineLinux a de vraies originalités et points forts, il vaut mieux aussi être au courant de ce qu'on y perd.

Certes, il n'est pas possible en pratique d'empêcher l'exportation d'un logiciel publié mais les contraintes juridiques ont déjà eu des effets par le passé. Par exemple, Debian a eu un dépôt non-us pour différencier les États-Unis et le reste du monde. Le but était de protéger Debian de poursuites juridiques.

Je ne connaissais pas duckDB non plus alors j'ai traîné un peu sur leur site.

Au vu de la page d'accueil, les cas d'usage semblent en effet les mêmes entre SQLite et duckDB. D'après un article de leur blog, duckDB intègre un système de recherche full-text alors que Sqlite a besoin d'un greffon pour cela.

D'un point de vue financier, MotherDuck est financé sur le NASDAQ pour le développement de duckDB. Il est possible de financer duckDB et d'influencer la gouvernance de duckDB (à partir de 10.000€ par an). De mémoire, il y a aussi une entreprise derrière SQLite, qui est payée pour faire des développements en fonction des besoins de gros utilisateurs.

De ce que je comprend, MotherDuck exploitera commercialement duckDB (service cloud), qui reste sous licence MIT.

C'est peut-être une bonne solution. C'est peut-être un bon investissement pour ceux qui ont pris des parts. Par contre, je ne sais toujours pas pourquoi passer de SQLite à duckDB pour du développement local, ni pourquoi passer de PostgreSQL à duckDB pour la production.

TMSC -> TSMC (pour Taiwan Semiconductor Manufacturing Company)

Oui, je pense que je me suis trompé : il ne devrait pas y avoir d'autres débats.

Les discussions actuelles parlent des prochaines étapes pour la mise en œuvre de la Résolution : changement du contrat social, maj de la documentation et du site, que faire pour que ce soit prêt pour la prochaine version, etc.

Ce graphe orienté montre l'ordre des votes. Le système de vote dans Debian utilise une variante (Schwartz) de la méthode de Condorcet qui permet aux votants d'ordonner leurs préférences.
Les arêtes montrent les différences de préférence entre deux choix. L'ordre est donc visible en regardant les nœuds de haut en bas: le plus haut (sur fond bleu) est le choix gagnant.

Le choix None of the above (représenté par un losange) représente un choix particulier présent à chaque vote. Chaque votant l'ordonne comme n'importe quel autre choix. Tout choix ayant une priorité plus faible que le choix None of the above signifie que le votant ne veut pas du tout de ce choix.

À noter que le choix gagnant implique un changement du contrat social (SC pour « social contact ») donc il n'est pas exclu qu'il y ait encore des débats pour arriver au résultat attendu.

J'arrive à avoir un résultat plus rapidement avec Gimp qu'avec Inkscape, d'où l'utilisation de Gimp. J'avais fait une première version avec Dia mais ce n'est pas idéal avec les boîtes qui se croisent.

J'ai des retours sur le graphisme mais pas sur la justesse du graphique, ce qui me manque un peu. Je posterai peut-être ailleurs une version améliorée pour tenter d'avoir des retours là-dessus.

Si quelqu'un avec les droits adéquats peut corriger ces deux détails :

« d'autant que que Gedit » : un « que » en trop
« ces fichiers configuration complexes » : il manque un « de » (fichiers de configuration)

Si je te demande d'ajouter 2 mois à un timestamp, en Python tu écrirais :
…
new_dt = dt + datetime.timedelta(months=2)

J'imagine que c'était un exemple pour illustrer l'idée principale, mais au cas où :

La syntaxe est correcte, mais datetime.timedelta n'accepte pas le paramètre month (justement parce que le nombre de jours diffère selon les mois):

timedelta(days=0, seconds=0, microseconds=0, milliseconds=0, minutes=0, hours=0, weeks=0)

https://docs.python.org/3/library/datetime.html?highlight=timedelta#datetime.timedelta

Il faut arreter de penser que la diffamation est illégale

La diffamation est illégale :
https://www.legifrance.gouv.fr/loda/article_lc/LEGIARTI000038313312/

Il y a cependant des limites comme l'exception de vérité par exemple.

Rappeler des faits ou citations publiques d'une personne n'est pas de la diffamation ; que cela plaise ou non à leur auteur n'a pas d'importance.

Vitesse de correction : ah ben ouais ils ont vite corrigé. Bon ils n'ont fait aucune recherche de variantes ce qui fait qu'on en est au 3 ou 4eme patch de suite a installer en deux semaines mais tout va bien ! Non cette prétendue différence de vitesse est principalement due aux gens qui ne comprennent pas ce que les éditeurs proprios font et croient qu'ils traînent des pieds.

Supposer que les éditeurs proprios font toujours des corrections lentes mais de qualité me semble optimiste. Certains éditeurs de jeux sont spécialistes des séries de patchs après la sortie commerciale d'un jeu.

De même, lorsqu'un éditeur proprio sort un correctif en urgence (suite à une faille zero day par exemple), on ne peut pas en déduire qu'il sera forcément mauvais.

Elle a voulu essayer le véganisme (du moins sur l'aspect alimentaire […]) et pensait que manger des œufs

Les œufs sont un produit animal et donc exclus d'une alimentation végane. Par contre, c'est compatible avec une alimentation végétarienne.

Pas d'erreur lors du git clone chez moi aussi.

[…] d'ou l'existence de git-lfs d'ailleurs (jamais testé, je sais pas ce que ça vaut, mais ça sent le workaround a 10 km);

D'après des développeurs de Mercurial, leur version de lfs est inspirée de celle de Git mais est mieux faite car ils ont aussi appris des défauts de git-lfs.

interface horrible (on va pas se mentir: utiliser git, ça va à peu près, quand on a l'habitude, mais il suffit de voir quelqu'un qui apprend… c'est pas simple du tout).

L'interface de Mercurial me semble mieux conçue que celle de Git. Les sorties sont homogènes entre elles. Par contre, étant moins utilisé, beaucoup moins d'infos sont disponibles, ce qui est moins pratique pour les débutants. De même, rebase doit être activé (c'est une ligne dans un .hgrc) ce qui peut surprendre quand on vient de Git.

Pour les autres éléments cités précédemment, je pense qu'il n'y a pas de différence significatives entre Git et Mercurial.

Quitte à renommer, il me semble préférable d'utiliser un nom plus générique (« webservercheck » ?). Si jamais d'autres serveurs sont ajoutés dans le futur, il n'y aura pas besoin de renommer à nouveau.

Je vois que l'existence d'apachectl est vérifiée et que des exécutions sont faites avec -V et -M.
Je ne sais pas si -t est omis parce que c'est hors périmètre (par exemple, si l'usage est de l'exécuter préalablement au script PHP).
Le paramètre -t permet de vérifier la syntaxe des configurations apache, la disponibilité des modules utilisés, etc. C'est utile pour une validation minimale des modifications de configuration avant de redémarrer Apache.

La réponse HTTP ayant le code 204 est No Content. Not Found ayant le célèbre code 404.