Diomidis Spinellis explique pourquoi il privilégie l’email aux messageries instantanées : une boîte unifiée (plus besoin de jongler entre Teams, WhatsApp, Slack, etc.), un archivage pérenne (ses emails remontent à 1986 !), des fonctionnalités avancées (filtrage, étiquetage, recherche), une communication asynchrone préservant la concentration, et une maîtrise totale de ses données (protocoles ouverts, stockage local, confidentialité). Contrairement aux plateformes propriétaires, l’email offre liberté, interopérabilité et protection contre la publicité ou l’obsolescence. Un plaidoyer pour un outil intemporel, productif et respectueux de la vie privée.
Thibault Buze explique dans ce troisième volet de Sous le capot du cloud le choix de Proxmox VE comme hyperviseur pour leur cloud interne, après une analyse des besoins clés : haute disponibilité (HA), automatisation, interopérabilité et simplicité d’opération. Parmi les alternatives (vSphere, Hyper-V, OpenStack), Proxmox s’impose pour son approche ouverte (KVM/QEMU, LXC), native HA (migration à chaud, bascule automatique), flexible (stockage iSCSI/NFS/ZFS, intégration TrueNAS) et automatisable (API, Terraform, cloud-init). L’architecture repose sur 3 hôtes minimum, des réseaux dédiés (management, stockage, données) et une intégration fluide avec Kubernetes (via Longhorn). Le tout est industrialisé en Infrastructure as Code (Terraform), garantissant reproductibilité et traçabilité. Points clés : séparation des plans de trafic, sauvegardes testées (Proxmox Backup Server), et monitoring rigoureux. Une solution souveraine, économique et scalable, idéale pour des clusters hébergeant 500 à 2000 pods.
La multi-location (multi-tenancy) en base de données désigne une architecture où une seule instance d’application et d’infrastructure sert plusieurs clients (tenants), tout en garantissant une isolation logique de leurs données. Ce modèle, largement adopté dans le cloud, permet une meilleure scalabilité, une réduction des coûts de maintenance et une optimisation des ressources. L’article détaille quatre approches principales : base unique avec schéma partagé (simple mais risqué en cas d’oubli de filtrage par tenant), base unique avec schémas séparés (meilleure isolation mais complexité accrue), base dédiée par tenant (isolation maximale mais coûteuse en gestion), et plusieurs bases avec tenants partagés (compromis entre coût et performance). Chaque méthode présente des avantages et des inconvénients selon les besoins en sécurité, performance et maintenance
L’article explique pourquoi l’auteur a abandonné Docker pour Podman, mettant en avant plusieurs avantages clés : Podman est sans démon, ce qui améliore la sécurité (moins de vulnérabilités liées à un processus root permanent) et réduit la consommation de ressources. Il s’intègre nativement avec systemd et Kubernetes, facilitant la gestion des conteneurs comme des services système et permettant une transition fluide vers des environnements de production. La migration est simple, car Podman utilise les mêmes commandes et fichiers Dockerfile que Docker, tout en offrant une approche plus sécurisée (mode rootless par défaut) et une meilleure alignement avec les pratiques Linux modernes. L’auteur souligne aussi que Podman encourage une architecture plus propre, comme l’utilisation d’un reverse proxy plutôt que l’exposition directe de ports privilégiés. En résumé, Podman se présente comme une évolution naturelle pour les développeurs cherchant plus de sécurité, de légèreté et de cohérence entre le développement et la production.
Un comparateur de distributions basées sur Android
L'article compare 2 manières de sérialiser des données : JSON et Proto (Protocol Buffer). Il conclue en donnant une règle : si des humains vont devoir lire les données échangées, préférer le JSON. Si ce sont des machins, préférer Proto.
L'article compare trois outils HTTP : Fetch API, Axios et Alova. Fetch API, intégré nativement dans JavaScript, est léger et idéal pour des requêtes simples mais nécessite une gestion manuelle pour des fonctionnalités avancées. Axios, bien que plus lourd, offre des fonctionnalités automatisées comme la gestion du JSON et des intercepteurs, le rendant adapté pour des applications complexes. Alova, quant à lui, combine la simplicité des requêtes avec des fonctionnalités avancées telles que la gestion de l'état et la mise en cache, ce qui en fait un choix optimal pour des applications front-end lourdes nécessitant une optimisation des performances.
Un comparatif des navigateurs (desktop, mobile) sur le respect de la vie privée
L'article explique ce qu'est un monolithe modulaire et quand il doit être préféré à une architecture de microservices.
Un article concis sur les différences entre WebSocket et Socket.IO pour la communication en temps réel
Un comparateur très complet sur les méthodes d'offuscation de mail
Tout est dans le titre
Une exploration de l'écriture d'un serveur HTTP minimaliste dans différents langages : Rust, Golang, Vlang, Ziglang, C et ASM
L'auteur expose des critiques envers bash, et pourquoi il se tourne à présent vers fish
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre