srb a écrit 90 commentaires

L'article sur les mythes autour de Systemd n'est pas maintenu :
- le mythe 27 parle de leur communauté active sur Google+
- l'article LWN parle de 150 binaires, le mythe 1 indique 69 binaires

ça reste probablement une bonne introduction pour comprendre la vision des deux parties.

Les deux claviers que je cite (ErgoDox et TrulyErgonomic) sont ortholinéaires, le Microsoft Natural Keyboard ne l'est pas. (En supposant qu'on parle bien de ce type de clavier)

Plus généralement, il existe plein d'autres claviers (Plank, X-Bows Nature, …) qui pourraient intéresser les aficionados de TypeMatrix. J'ai l'impression qu'ils sont ignorés.

Je comprends bien qu'on puisse avoir des préférences différentes : j'avais fait utiliser un TrulyErgonomic à un collègue utilisateur de TypeMatrix. Il l'a utilisé mais quand il est parti de l'entreprise, il ne l'a pas gardé alors qu'il pouvait. Je ne sais pas pourquoi mais j'en déduis qu'il l'a trouvé assez bon pour l'utiliser au quotidien mais pas assez pour le garder.

Reddit permet un système de modération différencié par subreddit (en gros des salons). Des modérateurs bénévoles font cette modération. C'est techniquement plus simple à mettre en place qu'une politique par instance et un système de filtrage d'instance.
Je pense que ça n'existe pas sur Twitter et Facebook parce que ce n'est ni dans la culture et habitude des utilisateurs ni dans celle de ces réseaux sociaux eux-même (et pas dans leurs intérêts non plus).

• le confort de frappe : étant donné la diversité des préférences en la matière (visible par la diversité des touches mécaniques par exemple), je ne commenterai pas ce point
• le peu de bruit : je suis d'accord
• le faible encombrement : si le problème principal est l'encombrement alors c'est sur l'augmentation de la place qu'il faut agir plutôt que sur le changement de clavier
• le mode numérique superposé : le Truly Ergonomic l'a aussi. L'ErgoDox est programmable donc c'est faisable aussi. Pour les autres claviers, je ne sais pas.

J'ai du mal à comprendre la popularité des claviers TypeMatrix aujourd'hui : la seule spécificité qui leur reste est la peau interchangeable. Il existe plein d'autres variantes de claviers ortholinéaires. Les claviers en deux parties ou avec des touches décalées verticalement me semblent beaucoup plus confortables.

Par exemple, la disposition des Truly Ergonomic garde les touches Entrée, Tab, etc. au centre mais l'ensemble de la disposition est meilleure grâce à l'angle entre les deux mains et les touches décalées. Je ne connais pas la version vendue actuellement : j'ai une version plus ancienne (sans les LED, sans marquage des touches et, de mémoire, des mécanismes Cherry Brown). La disposition physique reste identique.

L'usage quotidien d'un clavier coupé en deux (ErgoDox) me fait dire que ma position naturelle est plus les bras parallèles que la position du Truly Ergonomic mais j'aime bien le fait d'avoir toutes les touches (il y a une ligne de moins sur les ErgoDox).

Jamais compris pourquoi cacher les extensions ni pourquoi certaines personnes trouvent que c’est bien.

Sur un panel de une personne grand public à qui j'ai demandé après lui avoir montré comment les afficher (et que ça pouvait lui rendre service), la réponse a été « ce n'est pas joli ».

Ce comportement est plus dû à une optimisation de l'interpréteur cpython sur les petits nombres qu'à un manque de rigueur du langage. Il est basé sur ce comportement:

a = 1
b = 1
print(a is b)  # True
c = 2000
d = 2000
print(c is d)  # False

[Linus] se targue d’être historien

C'est un peu exagéré : il dit que c'est connaître l'histoire (« it's lack of history knowledge too »). Tout élève de Finlande doit probablement apprendre que la Finlande a été envahie par l'URSS (en 1939-40 puis retour de la guerre entre 1941 et 44).

Elle a été utilisée sur des articles anniversaire précédents.
Des commentaires des 24 ans donnent quelques infos sur l'image.

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)