jeanas a écrit 179 commentaires

Ah pardon, j'avais mal compris.

HTML n'ayant pas fondamentalement changé ces dernières années, il y a peu de raison que XSLT ne fonctionne plus.

https://developer.chrome.com/docs/web-platform/deprecating-xslt

Qu'entends-tu par le "phare" ?

Je ne comprends pas comment tu arrives à 10$/post, ce n'est pas plutôt 2000 crédits/post × 0.1¢/crédit = 2$/post (en sachant que tu peux diminuer le prix de moitié si tu en achètes pour 50$) ?

Tiens, dans la catégorie « petits services », je trouve aussi https://feedmail.org (permet de s'abonner par email à un flux RSS, et tu peux apparemment générer un lien d'abonnement vers ton flux et faire en sorte de payer toi-même les frais d'envoi de ceux qui s'y abonnent).

D'abord, soyons clairs : oui, c'est la merde. C'est un problème qui devrait avoir des solutions archi-faciles en 2025 et qui n'en a pas. Notamment parce que l'email, qui au départ devait être décentralisé, se retrouve de facto largement centralisé non seulement parce que les utilisateurs vont en masse chez Google comme d'habitude, mais aussi parce que les gros fournisseurs rendent la vie dure aux petits serveurs au motif plus ou moins honnête de lutter contre le spam. Envoyer des emails en masse devient de facto payant, soit en argent à des entreprises qui font payer la réputation de leurs serveurs, soit en temps de sysadminage. (J'ai défendu dans un billet de blog l'idée que la bonne solution pour lutter contre le spam serait un système avec un composant centralisé analogue au DNS, où la création d'une adresse mail serait payante. Mais trêve de rêveries, je reviens en mode « répondre à ton problème dans le monde imparfait dans lequel nous vivons ».)

Pour choisir un serveur depuis lequel envoyer tes emails, il faut commencer par évaluer les besoins. Tu dis avoir 2000 personnes à qui envoyer chaque email. Un rapide coup d'œil aux archives de ta liste suggère que cela fait de l'ordre de 5000 emails envoyés par mois. C'est trop pour un hébergeur de boîte mail personnelle typique. Tu peux te tourner vers un service comme Sendgrid, Mailgun ou Postmark. C'est scandaleusement cher, au moins 15€/mois pour les trois que je viens de citer. Tu peux te tourner vers un petit service comme mailmanlists, mais la délivrabilité de tes emails sera dépendante de facteurs hors de ton contrôle, et manifestement l'expérience n'a pas bien fonctionné pour toi. Ou tu peux te résoudre à héberger ton propre serveur mail. C'est ce que j'ai dû faire personnellement, au moment de migrer une mailing list vers un forum (https://lilypond.community).

La bonne nouvelle, c'est que ce n'est pas si compliqué que ça de nos jours d'installer le serveur lui-même. J'étais complètement débutant en sysadminage à l'époque, et je me suis perdu dans Postfix, Dovecot et autres outils habituellement recommandés, mais j'ai trouvé Stalwart qui fait tout en un (SMTP et IMAP), avec une configuration que j'ai trouvée facile et une documentation à peu près lisible. Je précise que c'était il y a deux ans et à vue de nez le machin a l'air d'être devenu plus commercial depuis, mais j'ai plutôt apprécié.

La mauvaise nouvelle, c'est que tu vas devoir mettre ton serveur sur un VPS chez un fournisseur de cloud (plutôt que dans un coin chez toi, car une IP résidentielle se ferait bloquer en moins de deux, apparemment), et ces fournisseurs ferment souvent le port 25 pour éviter de devenir des fermes à spam. Par exemple, il est impossible de le rouvrir chez DigitalOcean, et chez Hetzner, j'ai dû attendre un mois avant de pouvoir faire une demande de déblocage au support. C'est un point à vérifier avant de choisir l'hébergeur.

L'autre mauvaise nouvelle, c'est qu'il va falloir faire un petit peu attention à la réputation de ton serveur (https://www.dnsbl.info est un outil assez utile). Dans mon cas, le principal problème est que Hotmail rejetait complètement les emails de mon serveur dès le premier, et j'ai dû me battre pour arriver à joindre un humain chez le support, mais ils ont fini par le débloquer. À part ça, je dois dire que je suis agréablement surpris qu'il n'y ait pas eu à ma connaissance d'autre problème de délivrabilité. Ce n'est que ma propre expérience.

À part le serveur, l'autre problème est de trouver un outil qui permette aux gens de s'abonner via un formulaire sur une page Web (avec un email de confirmation), et qui insère dans chaque email envoyé un lien de désinscription (de préférence en fin d'email et dans l'en-tête List-Unsubscribe). Ça, c'est tellement peu de code que j'aurais personnellement tendance à écrire moi-même un petit script, mais tu peux en trouver des centaines en PHP ou autre.

HTH

J'oubliais. Avant de mettre en place un cache Squid, je ferais une chose à la fois en commençant par faire fonctionner le site sans cache. D'ailleurs, pour un petit site, je ne vois pas l'intérêt du cache.

Il avoir plus d'informations pour pouvoir aider précisément, notamment le contenu du fichier de configuration d'Apache. Néanmoins je vois déjà un certain nombre de problèmes :

1. Quand on visite https://www.histoire.espacedesgaulois.org, la connexion au serveur ne peut même pas commencer, car il n'y a aucune entrée DNS pour www.histoire.espacedesgaulois.org (comme on peut le voir en tapant host www.histoire.espacedesgaulois.org). Il y en a bien une pour histoire.espacedesgaulois.org, donc soit tu veux vraiment le www (ce qui serait inhabituel pour un sous-domaine et peut compliquer les choses car s'il est possible pour un certificat TLS (SSL) de couvrir un domaine et tous ses sous-domaines, il est impossible de couvrir aussi les sous-sous-domaines), soit tu corriges l'adresse en https://histoire.espacedesgaulois.org.

2. L'erreur « Could not reliably determine the server's fully qualified domain name » indique qu'il manque la directive ServerName. Comme tu as manifestement plusieurs sites, espacedesgaulois.org et histoire.espacedesgaulois.org, à héberger sur le même serveur (je vois la même IP dans le DNS des deux), il va falloir deux blocs VirtualHost, chacun avec un ServerName qui indique à quel domaine il s'applique. Et comme le site doit être servi en HTTP et en HTTPS, cela fait quatre VirtualHost en tout. Je recommande de rediriger HTTP vers HTTPS, comme dans l'exemple à la fin de ce commentaire.

3. Le certificat ssl-cert-snakeoil.pem, comme son nom l'indique (snake oil = poudre de perlimpinpin), ne sert qu'à faire des tests. Il est auto-signé, c'est-à-dire qu'il ne certifie pas réellement que le serveur est celui qu'il prétend être, et donc les navigateurs Web rejettent ce type de certificats. Il faut obtenir un vrai certificat via Gandi, ou bien via un service comme Let's Encrypt. Soit tu as un certificat wildcard, qui s'applique à tous les sous-domaines, auquel cas le même peut servir pour espacedesgaulois.org et histoire.espacedesgaulois.org (mais pas pour www.espacedesgaulois.org car c'est un sous-sous-domaine), soit il faudra deux certificats séparés.

Je termine par un exemple de configuration Apache :

# espacedesgaulois.org servi en HTTPS (port 443)
<VirtualHost *:443>
  ServerName espacedesgaulois.org
  DocumentRoot /chemin/vers/les/fichiers/de/espacedesgaulois.org/

  SSLEngine on
  SSLCertificateFile /chemin/vers/le/certificat.pem
  SSLCertificateKeyFile /chemin/vers/la/clé.key
  SSLCertificateChainFile /chemin/vers/les/certificats/intermédiaires.ca-bundle
</VirtualHost>

# espacedesgaulois.org en HTTP (port 80) redirige vers HTTPS
<VirtualHost *:80>
  ServerName espacedesgaulois.org
  Redirect permanent / https://espacedesgaulois.org/
</VirtualHost>

# histoire.espacedesgaulois.org servi en HTTPS (port 443)
<VirtualHost *:443>
  ServerName espacedesgaulois.org
  DocumentRoot /chemin/vers/les/fichiers/de/histoire.espacedesgaulois.org/

  SSLEngine on
  SSLCertificateFile /chemin/vers/le/certificat.pem
  SSLCertificateKeyFile /chemin/vers/la/clé.key
  SSLCertificateChainFile /chemin/vers/les/certificats/intermédiaires.ca-bundle
</VirtualHost>

# histoire.espacedesgaulois.org en HTTP (port 80) redirige vers HTTPS
<VirtualHost *:80>
  ServerName histoire.espacedesgaulois.org
  Redirect permanent / https://histoire.espacedesgaulois.org/
</VirtualHost>

Je suis le premier à dire que le milieu du libre doit faire des efforts pour aller vers les gens, produire des outils faciles à utiliser par Monsieur et Madame Michu, ne pas s'adresser uniquement aux geeks, à défendre GNOME quand ils font des sacrifices sur les fonctionnalités au profit de la simplicité d'utilisation pour le tout-venant, etc.

Néanmoins, je pense aussi qu'il faut accepter que les solutions décentralisées ne seront jamais tout à fait aussi fluides d'utilisation que des systèmes complètement centralisés comme Google Drive et GitHub, parce que la centralisation est intrinsèquement plus pratique (un seul compte, une seule interface, pas de question d'interopérabilité, etc), et qu'il faut accepter de perdre ses avantages (tout en minimisant la perte), ce qui passe par la sensibilisation à ses problèmes (concentration des risques, création de pouvoirs non-élus plus puissants que des États, etc).

Mon sujet principal est une variante spéculative de HoTT.

https://linuxfr.org/users/ysabeau/liens/fondation-python-the-psf-has-withdrawn-a-1-5-million-proposal-to-us-government-grant-program

Tu fais une thèse en théorie de la démonstration ? ou en calculabilité ?

Théorie des types

Je viens de lire l'article (https://arxiv.org/pdf/2507.22950). Il se trouve que les théorèmes de Gödel font partie des bases de mon propre domaine de recherche (je suis en thèse). Je n'ai pas le temps de développer mais disons simplement que cet article est du vent. Il ne dit strictement rien d'intéressant et ne prouve certainement pas que nous ne vivons pas dans une simulation.

Pour autant que je le sache, la notion de déterminant d'une application linéaire est bien définie uniquement dans le cas particulier où l'espace est de la forme ; et dans ce cas le déterminant est celui de la matrice dans la base canonique.

Pour moi (et Wikipédia), le déterminant d'une application linéaire est par définition le déterminant de sa matrice dans une base quelconque (mais la même au départ et à l'arrivée). On vérifie que ça ne dépend pas de la base.

Pour des démonstrations de Math exigeant la compréhension fine de nombreux concepts, je me demande bien comment l'on peut être sûr de pouvoir valider par soi-même une démonstration sans passer par l'approche de la revue par des pairs reconnus comme experts dans leur domaine.

Rappelons tout de même que le Frido se place au niveau de l'agrégation, qui est un concours d'enseignement, et dont les épreuves orales demandent de présenter un plan de cours sur un sujet au programme. Un niveau, donc, où on est censé savoir en principe reconnaître une démonstration correcte ou non (ce qui n'empêche évidemment pas de se tromper parfois, ça arrive même aux meilleurs) et avoir une maîtrise suffisante des concepts en jeu (qui font partie du cursus mathématique universitaire standard, pas de domaines de recherche très spécialisés) pour appliquer cette compétence de manière raisonnablement efficace sur ces preuves en particulier.

Sur ce point, chatGPT peut en savoir plus que moi. Par exemple je ne voyais pas comment démontrer qu'une transvection est de déterminant 1. C'est chatGPT qui m'a mis sur la piste du lemme des déterminants que je ne connaissais pas.

Ça me paraît bien compliqué. En développant juste le déterminant comme somme sur les permutations, ça marche, non ? (On peut poursuivre cette discussion ailleurs si tu veux.)

Aparté : je n'ai pas compris le lien que tu fais entre mesure et compacité.

Je demande si il est vrai que tout ensemble Dedekin-fini totalement ordonné a un maximum.

À mon avis la preuve donnée par Asaf Karagila (et qui a 5 votes positifs) a au moins un trou ; j'explique dans les commentaires ce qui ne me va pas. Si vous avez une idée de comment compléter, n'hésitez pas.

Je n'ai pas relu la preuve d'Asaf Karagila, mais je viens de poster une nouvelle réponse avec une preuve différente et très détaillée.

Merci mais je ne comprends pas en quoi ça répond à ma question. La sélection primaire de X11, c'est ce qui change dès que tu sélectionnes du texte, sans même le copier. Qu'est-ce que ça a à voir avec les raccourcis clavier, gestes touchpad ou autres interactions qui sont configurés pour copier la sélection ?

Hein ? Mais le fait qu'un clic du milieu fasse ou non un copier-coller dépend de GNOME/KDE/ton window manager, pas du protocole Wayland ou X11 qu'il utilise pour communiquer avec les applications, non ?

Au temps pour moi.

Si les universités belges sont aussi sous-financées que les françaises, c'est un peu normal qu'elles aient à faire des choix budgétaires difficiles. Il y a tout de même une différence entre « fermer la bibliothèque pour faire des étudiants des bons petits consultants obéissants et employables qui n'ont pas besoin de réfléchir donc pas besoin de livres » et « fermer la bibliothèque parce que sinon on ne peut pas remplacer les deux collègues de lettres classiques et trois de maths qui partent à la retraite étant données les dernières coupes budgétaires ».

Avec Nextcloud, tu as une interface Web à ton calendrier et un serveur Caldav, et en prime tu peux facilement y ajouter d'autres usages (Carddav pour les contacts, partage de fichiers, etc.).

Aujourd'hui, beaucoup de sites utilisent des certificats à durée de vie relativement longue, typiquement un an, obtenus de la part du registrar DNS, et renouvelés à la main en demandant un nouveau certificat au registrar et en uploadant le fichier qu'on obtient sur le serveur. Pour eux, ce ne sera plus vraiment tenable, s'il faut faire cette manip tous les mois, donc tout le monde va devoir basculer sur l'autre méthode, celle du renouvellement automatique, qui est déjà très commune parce que Let's Encrypt, la principale autorité de certification à être gratuite, ne fournit déjà que des certificats à durée de vie assez courte.

(Moi, ça m'embête un peu, parce que les outils de renouvellement automatique comme acme.sh et Certbot m'ont causé quelques misères. J'espère que ce sera plus au point pour mes usages d'ici-là.)

C'est une délibération du CA/Browser Forum, un consortium qui rassemble la plupart des navigateurs Web et des autorités de certification qui délivrent les certificats TLS (que tout le monde continue d'appeler SSL), plus quelques autres.

Cette décision signifie donc probablement que presque toutes les CAs vont réduire la durée de validité maximale de leurs certificats, et que les navigateurs vont se mettre à refuser les certificats avec des durées plus longues.