flan a écrit 1805 commentaires

Je me demande si on ne pourrait pas remplacer WebDAV par un protocole basé sur les websockets, pour éviter tous ces surcoûts liés aux en-têtes.

Dans ce cas, c’est la contrepartie d’un risque pris.

J’aurais bien parlé de ruse plutôt que de tromperie.

Si ce sont des données volées, ça reste du recel.

L’iPhone utilise un chargeur USB, et le cordon sera de toute façon fourni, qu’il soit Lightning ou USB-C.

Les téléphones ont une durée de vie de plus en plus longue, ça n’a rien de spécifique au Fairphone. Mes deux iPhone précédents (qui sont aussi mes deux premiers) ont duré dans les 5 ans, et j’en vois de bien plus vieux autour de moi.

On reconnaît plutôt bien la plupart des régimes communistes là-dedans.

Quelle est ta définition d’extrême-droite ?

Je m'étais servi de WeasyPrint, mais malheureusement pour pas mal de cas l'absence de notes de bas de page a été rédhibitoire et j'avais dû générer du LaTeX.

C'est bien dommage, WeasyPrint été mieux sur tous les autres points et avec cette version actuelle, ça aurait parfaitement fait le boulot.
En tout cas, sacré travail !

C’est quand même sympa d’avoir des fenêtres.

C'est nettement plus simple pour les lecteurs d'écran pour personnes aveugles. Tu peux choisir tes couleurs (texte/fond) de façon générale et sans risquer qu'elles soient pourries, ce qui est utile pour les personnes mal-voyantes, ou atteintes de dyschromatopsie.

Au contraire, le HTML permet de donner des indications sur le rôle de chaque contenu, faire de la mise en forme pour permettre d'aller à l'essentiel, d'utiliser des couleurs, etc.
Je ne vois vraiment pas comment du texte brut pourrait être plus expressif que du HTML.

Le raisonnement de l'article est quand même passablement idiot : ces statistiques ne montrent pas qu'on n'est pas pragmatiques, elles montrent simplement que les diplômes sont utiles.

S'il n'y avait aucune différence entre le fait de faire des études (et donc d'avoir un diplôme) et de ne pas faire d'études, cela signifierait que les études ne servent à rien. Bien heureusement que quelqu'un qui a fait des études a plus de chances d'être compétent (dans son domaine, évidemment) qu'une personne sans diplôme !

Malheureusement, on trouve toujours des cas ayant eu leur diplôme dans une pochette surprise, mais ça dépend pas mal des spécialités.

Un peu comme les bases de données, […]

Mais OpenLDAP est une base de données. Elle n'est pas compatible SQL, voilà tout.

Mais… Le truc super, c'est que les classes de base sont bien définies et ont peu bougé depuis des années, idem pour les protocoles réseau, ce qui donne un niveau d'interopérabilité incroyable sur des systèmes hétérogènes, comparativement à d'autres mécanismes plus souples.

Classes bien définies… mais pas forcément bien pratiques pour autant : on a par exemple des composants qui veulent du posixGroup/posixUser et d'autres du Group/inetOrgPerson, alors que les deux sont incompatibles. La solution est donc d'avoir les informations en doublon si tu veux vraiment tout baser sur LDAP.
D'autre part, plein de logiciels acceptent LDAP… mais sans donner beaucoup de possibilité pour configurer. Si tu as un LDAP qui n'est pas accessible anonymement en lecture et que tu ne fais que de l'authentification sans mot de passe (avec Kerberos), c'est possible mais presque personne ne prévoit ce cas.

J'avais eu les stats d'un FAI français, et c'était encore plus important (de l'ordre de 80 ou 90%).

C'est sûr, le moindre film en HD représente des milliers de courriels.

Pour Debian, ces défauts sont compréhensibles car le format est vieux.

Certains défauts sont beaucoup moins acceptables pour des systèmes plus récents qui n'apportent rien aux systèmes déjà existants alors qu'ils auraient pu en reprendre un. La résolution des dépendances est un problème résolu du côté du client, qui est complètement indépendant du dépôt. Par exemple, poetry (client pypi) a un algorithme de résolution de dépendance différent de pip.

Pourquoi systématiquement partir du principe que les autres correspondants sont à la fois impolis et incompétents ?

• le texte brut me pose pas mal de problèmes, on ne peut par exemple pas faire de la typographie même de base (couleur, italique, indices, exposants, gras, …), ni faire de liens utilisables.

• garder l'historique est bien pratique quand le message est transmis à une personne qui n'était pas dans les échanges initiaux (très fréquent). Bien évidemment, il faut que tout le monde utilise la même chose… et continuer au-dessus du dernier message permet d'accéder directement au dernier message (donc la partie utile dans 99% des cas).

C'est vrai, il peut y avoir des cas d'usages. Désolé d'avoir été aussi péremptoire. Mais je pense que c'est loin d'être la majorité, ou alors tu va me dire que tu utilises du haskell, du java, du C#, du C, du python, du JS, du perl et whatnot dans la même boîte?
Bon, techniquement, perl sous debian t'as pas le choix, python n'est pas le plus simple a esquiver et maintenant ils commencent a mettre JS en dépendance obligatoire des paquets de documentation (ce qui me fait vraiment chier, au passage), mais l'idée est la: je doute sincèrement que l'accès à la totalité de l'archive Debian soit nécessaire dans la plupart des cas.

En pratique, il est bien plus simple de cloner l'intégralité du miroir Debian qu'une sélection de paquets. D'autre part, il est vite pénible d'ajouter progressivement les paquets alors qu'un miroir Debian ou Ubuntu ne pèse rien (dans les 200 Go).

Par contre, dans les structures que j'ai connues, il y avait un peu de tout (Python, Java, Ruby, C, C++, PHP, JS …), donc besoin de miroirs pour ces langages.

Il fut une époque ou python était très peu utilisé, lui aussi. Troll à part, tu as raison, mais il n'empêche qu'on ne peux pas parler de réinventer la roue quand quelqu'un utilise ar, surtout quand le projet en question est loin d'être jeune.

Ça tombe bien, je n'ai jamais parlé de réinventer la roue mais d'avoir des défauts. Je considère en effet qu'utiliser deux formats d'archives différents, dont un peu fréquent avec peu de bindings dans les langages classiques, est un défaut.

Quand je pars à l’étranger, je ne veux avoir accès à internet qu’à travers un VPN. Si je n’ai plus de VPN, je n’ai plus accès à internet non plus.

ar existe depuis longtemps et utilisé dans des cas bien précis, mais est finalement très peu utilisé en comparaison de zip ou tar.XX, et surtout n'est facilement utilisable qu'en ligne de commande. Si tu veux faire du Python (comme c'était mon cas), tu n'as pas de de moyen de l'utiliser aussi simple que pour faire du zip ou du tar.gz (i.e., bibliothèque standard ou purement Python).

Je ne pense pas qu'il soit pertinent de chercher a dupliquer la totalité des paquets de l'archive Debian pour se monter une reprepro local à la boîte, pour le coup. Un système de type serveur sous Debian, avec une install raisonnée, le coeur du système tiens sur environ 300 paquets, chaque nouvel fonctionnalité apportant sont lot de paquets (et ça peut monter très vite selon les technologies, c'est vrai, mais ce n'est pas lié à apt) mais je doute très fortement qu'une boîte ait besoin de tous les DEs et leur tétrachiée de dépendances…

Si, ça arrive. Personnellement, j'ai toujours bossé sur des environnements sans accès à internet, donc avec des copies complètes des dépôts en local (faisable avec du Debian ou Ubuntu, mais rarement faisable avec les dépôts de langages comme Python ou npm qui sont énormes).

La, vraiment, je ne comprend pas comment on peut sérieusement mettre ça dans un message intitulé "réinventer la route"… Tu parles d'un format d'archive qui existe depuis 1971 selon wikipedia, et qui est actuellement toujours très utilisé pour… la compilation d'outils natifs.

ar existe depuis longtemps, mais est très peu utilisé en comparaison de zip ou tar.XX, et surtout n'est facilement utilisable qu'en ligne de commande (tu n'as pas de version Python, par exemple).

• Ça t'empêche d'utiliser la version fournie par ta distribution (par définition, tu n'auras qu'une seule version d'installée sur ton système),
• Ça t'oblige à garder une vieille version en production,
• Ça t'empêche d'utiliser des ports standards.

C'est difficile, mais tout le monde réinvente la roue sans trop de poser de question, malheureusement.
Au final, on se retrouve avec plein de solutions différentes, avec toutes des inconvénients différents (certaines plus que d'autres).

Quelques défauts à travers des différents formats que j'ai fréquentés :
- le miroir est codé en dur (snap)
- le protocole et le port sont codés en dur (docker)
- l'index est constitué d'objets sérialisés (Ruby) donc presque illisible dans un autre langage (à moins de recoder la désérialisation d'objets Ruby)
- pas de signature de l'index (Ruby, …)
- plein de fichiers à télécharger (apt) ce qui rend le mirroring compliqué
- l'archive ne contient pas (toujours) toutes les métadonnées (java)
- pas de schéma de numérotation de version imposé (Python, Ruby, npm, …)
- système de signature spécifique à un OS (WinGet, de mémoire)
- formats d'archives peu classique (.deb qui utilise des ar)
- un service tiers est codé en dur (Ansible Galaxy, qui se repose sur le fait que Github ne change pas ses URL et reste gratuit)
- un protocole qui compte beaucoup sur les headers HTTP, donc impossible d'utiliser un autre protocole (Docker)
- un index basé sur git, donc compliqué à reproduire (Rust)
- protocole à moitié codé en dur (apt fonctionne mal en file://)

Mais à nouveau, comment fais-tu pour tout mettre à jour en même temps ?

Les dates de disponibilité dépendent d'une plate-forme à l'autre, et si tu mets à jour ton serveur en premier, tes clients n'auront plus accès au VPN et ne pourront donc plus faire la mise à jour.