varlog/_cache/similar/e0e64681-1da0-44a6-963e-4a5e924147e5.json

[{"uuid":"c53d0248-04ab-4e50-844f-7b84c4c56cf1","slug":"20230122-ipfs","title":"IPFS InterPlanetary File System","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-01-26 21:20:56","created_at":"2023-01-26 21:20:56","updated_at":"2023-01-26 21:20:56","tags":[],"plain":"IPFS (InterPlanetary File System) est un protocole de stockage de fichiers distribué qui permet de stocker et accéder à des fichiers à travers un réseau pair-à-pair. Il utilise une adressage basé sur les hash des fichiers pour identifier de manière unique les fichiers, ce qui permet une résistance aux erreurs de transmission et une sécurité accrue. Il vise à remplacer les systèmes de stockage centralisés par un système décentralisé et distribué. Techniquement, IPFS fonctionne en utilisant un réseau pair-à-pair pour stocker et accéder aux fichiers. Les fichiers sont divisés en morceaux appelés \"blooms\" qui sont ensuite identifiés par un hash unique. Ces hash sont utilisés pour créer des adresses uniques pour chaque fichier, appelées \"CID\" (Content Identifier). Lorsqu'un utilisateur veut accéder à un fichier, il envoie une demande à travers le réseau IPFS en utilisant la CID. Les nœuds du réseau recherchent ensuite les blooms correspondants au hash et les rassemblent pour reconstituer le fichier original. Les blooms peuvent être stockés sur plusieurs nœuds différents, ce qui permet une résilience accrue et une distribution de charge. Il existe également des protocoles de mise en cache et de routage pour gérer efficacement les demandes et les réponses sur le réseau, ainsi que des protocoles de sécurité pour s'assurer que les données restent privées et intègres. En résumé, IPFS utilise un système de stockage distribué qui repose sur des hash uniques pour identifier les fichiers, un réseau pair-à-pair pour stocker et accéder aux fichiers, des protocoles de mise en cache, de routage et de sécurité pour gérer efficacement les demandes et réponses sur le réseau. IPFS utilise un système de recherche de pair à pair pour localiser les fichiers. Lorsqu'un utilisateur envoie une demande pour un fichier en utilisant sa CID, cette demande est propagée à travers le réseau à différents nœuds. Les nœuds envoient ensuite des demandes à leurs pairs connectés pour localiser les blooms correspondants au hash. Cependant, il existe des protocoles qui permettent d'utiliser des annuaires pour stocker des CIDs de manière centralisée pour faciliter la recherche de fichiers. Ces protocoles permettent de stocker des CIDs dans un annuaire centralisé et de les utiliser pour la recherche de fichiers, cependant ils ne sont pas obligatoires pour utiliser IPFS. Certains projets tels que \"IPNS\" (InterPlanetary Name System) permettent de créer des alias de hash pour des adresses IPFS pour une recherche plus simple pour les utilisateurs. Le projet IPFS est porté par la fondation Protocol Labs, une organisation à but non lucratif basée aux États-Unis. Protocol Labs est un groupe de recherche et de développement qui se concentre sur la création de protocoles et de technologies pour améliorer l'Internet.\nIPFS est un des projets majeurs de Protocol Labs, qui a également d'autres projets tels que : Filecoin, libp2p, IPLD, multiformats, entre autres.\nIPFS a été créé en 2014 par Juan Benet, qui est également fondateur et PDG de Protocol Labs. Depuis sa création, le projet a reçu un financement conséquent de différents investisseurs et est devenu un projet open-source très populaire, utilisé par de nombreux projets et entreprises. PeerTube est un projet open-source qui a pour but de fournir une plateforme de streaming vidéo décentralisée et respectueuse de la vie privée. Il utilise IPFS pour stocker les vidéos de manière distribuée sur plusieurs nœuds, ce qui permet de réduire la charge sur les serveurs centraux et d'améliorer la résilience du système. Les utilisateurs peuvent également héberger leurs propres nœuds PeerTube pour contribuer à la distribution des vidéos. Cela permet également de limiter les risques de censure en rendant plus difficile pour les tiers de supprimer les vidéos. En utilisant IPFS, PeerTube se distingue des plateformes de streaming centralisées comme YouTube ou Vimeo qui utilisent des serveurs centraux pour stocker et distribuer les vidéos, et qui ont donc un point unique de défaillance, et sont plus soumis aux risques de censures. Il existe de nombreux projets et solutions qui utilisent IPFS pour différentes raisons. Voici quelques exemples :\nStorj: une plateforme de stockage décentralisée qui utilise IPFS pour stocker les fichiers de manière distribuée.\nTextile: une plateforme de stockage et de partage de photos décentralisée qui utilise IPFS pour stocker les photos de manière sécurisée et privée.\nEternum: un jeu en ligne qui utilise IPFS pour stocker les données de jeu de manière distribuée.\nFleek: une plateforme de développement web décentralisée qui utilise IPFS pour stocker les sites web de manière distribuée.\nFilecoin: un projet qui utilise IPFS pour stocker les fichiers de manière distribuée, et qui utilise un marché pour récompenser les utilisateurs qui hébergent des fichiers. Il y a aussi des projets qui utilisent IPFS en combinaison avec d'autres protocoles décentralisés tels que blockchain pour offrir des solutions à des problèmes spécifiques. Des entreprises utilisent IPFS pour améliorer les performances de leurs applications et services, ou pour offrir des solutions de stockage distribué. IPFS est un protocole ouvert, donc il est possible de l'utiliser de différentes manières, et il est en constante évolution, donc de nouvelles utilisations pourraient apparaître. <u>Sites et références</u>\nhttps:ipfs.tech/\nhttps:protocol.ai/"},{"uuid":"e1e8a0c1-6971-4357-9aaa-7e7a748922f3","slug":"quand-systemd-remplace-cron-pourquoi-et-comment-migrer-ses-taches-planifiees","title":"Quand systemd remplace cron : pourquoi (et comment) migrer ses tâches planifiées","category":"informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2026-06-01 07:56","created_at":"2026-05-12 13:57:29","updated_at":"2026-05-12 13:58:58","tags":[],"plain":"Cron tourne sur Linux depuis 1975. Il a fait son temps pour beaucoup d'usages : voici ce que les timers systemd apportent, et comment basculer sans tout casser.\r\n\r\nPourquoi cron reste partout\r\n\r\n est l'un des plus anciens outils Unix encore en service. Son principe tient en deux idées : un démon qui se réveille toutes les minutes, et un fichier texte — la crontab — où chaque ligne décrit une commande et son moment d'exécution avec cinq champs (minute, heure, jour du mois, mois, jour de la semaine).\r\n\r\n\r\n\r\nCinquante ans plus tard, ça marche. C'est installé partout, c'est documenté à mort, ça tient sur une ligne, et n'importe quel administrateur sait lire . Pour beaucoup de besoins simples — « lancer ce script tous les jours à 2h du matin » — cron reste le bon choix.\r\n\r\nLe problème est que les besoins ont rarement été aussi simples depuis longtemps.\r\n\r\nLes limites de cron qu'on finit toujours par rencontrer\r\n\r\nÀ chaque administration de serveur sérieuse, on retombe sur les mêmes frustrations.\r\n\r\nLa machine était éteinte au moment du job. Cron saute purement et simplement l'occurrence ratée. Si le portable de l'utilisateur dormait à 2h, la sauvegarde quotidienne n'aura pas lieu — point. Le job s'exécutera de nouveau le lendemain à 2h, sans rattrapage, sans alerte.\r\n\r\nLes logs sont dispersés ou perdus. Par défaut, la sortie standard du job est envoyée par mail à l'utilisateur (si  est défini et qu'un MTA tourne) ou simplement perdue. Le démon lui-même logue dans syslog quand il démarre un job, mais pas son contenu. Diagnostiquer pourquoi un job a échoué la semaine dernière relève souvent de l'archéologie.\r\n\r\nPas de dépendances. Un job qui doit attendre que le réseau soit monté, qu'un point de montage soit présent, qu'un autre service ait fini son démarrage : cron ne sait pas exprimer ça. La parade habituelle — un  ou un  suivi d'une boucle d'attente — fonctionne mais reste un bricolage.\r\n\r\nPas de recouvrement entre exécutions. Si un job de 5 minutes en prend 7 ce jour-là, cron lance la prochaine occurrence pile au moment où la précédente tourne encore. Deux instances simultanées d'un script de synchronisation, c'est rarement ce qu'on veut.\r\n\r\nPas de jitter, pas de randomisation. Quand cinquante VMs lancent leur  toutes en même temps à 6h25 (l'heure d'anacron par défaut sur Debian), le pic de charge sur l'hyperviseur est garanti. Cron n'offre aucune primitive pour étaler les exécutions.\r\n\r\nPas de visibilité globale. Pour répondre à « quels jobs vont tourner aujourd'hui sur cette machine ? », il faut lire la crontab système, les crontabs utilisateur (), le contenu de , , , etc. Aucune commande ne donne la vue consolidée.\r\n\r\nPas d'isolation, pas de quota. Le job s'exécute avec les privilèges et les ressources du shell qui l'a lancé. Aucune façon native de limiter à 50 % de CPU, à 1 Go de RAM, ou de couper si ça dépasse 10 minutes.\r\n\r\nAucun de ces points ne rend cron inutilisable. Mais accumulés sur une dizaine de jobs critiques, ils transforment l'administration en travail de surveillance permanente.\r\n\r\nCe qu'apporte un timer systemd\r\n\r\nSur toute distribution Linux moderne basée sur systemd (la quasi-totalité, hors BSD, Alpine, Gentoo et quelques cas particuliers), une alternative native existe : les timers. Le principe est différent dès le départ.\r\n\r\nUn timer systemd, c'est deux fichiers au lieu d'une ligne :\r\nUn fichier  qui décrit ce qu'il faut faire — exactement comme on décrit un service classique, en mode  pour un job ponctuel\r\nUn fichier  qui décrit quand le faire — ce sont les règles de déclenchement\r\n\r\nCette séparation entre le « quoi » et le « quand » est plus verbeuse au départ, mais elle débloque tout le reste.\r\n\r\nUne syntaxe d'horaire lisible\r\n\r\nLà où cron oblige à mentaliser , systemd écrit :\r\n\r\n\r\n\r\nEt la commande  valide l'expression en montrant la prochaine exécution prévue. Une erreur de jour-de-semaine ou un décalage horaire ne plante pas en silence : on le voit avant de déployer.\r\n\r\nD'autres formes utiles que cron ne sait pas exprimer :\r\n\r\n\r\n\r\nLe support natif des fuseaux horaires est une avancée significative pour qui gère des serveurs distribués géographiquement — cron ignore tout du concept et tourne sur le fuseau du système.\r\n\r\nDu temps relatif, pas seulement du temps absolu\r\n\r\nCron raisonne uniquement en horloge murale (« tel jour, à telle heure »). systemd ajoute le temps monotone, relatif à un événement :\r\n\r\n\r\n\r\n règle proprement le problème des exécutions qui se chevauchent : la prochaine instance se déclenche 6 heures après la fin de la précédente, pas 6 heures après son démarrage. Aucune équivalence simple en cron.\r\n\r\nLe rattrapage des exécutions ratées\r\n\r\nUne seule ligne change tout :\r\n\r\n\r\n\r\nAvec cette option, systemd mémorise la dernière exécution réussie. Si la machine était éteinte au moment prévu, le job se déclenche dès le démarrage suivant (après le  éventuel, voir plus bas). Pour un portable, un poste de développement, ou n'importe quelle machine qui n'est pas en service 24/7, c'est une différence majeure de fiabilité.\r\n\r\nDu jitter intégré\r\n\r\n\r\n\r\nLe déclenchement se fait à un instant aléatoire dans la fenêtre . Quand cinquante machines lancent leur mise à jour quotidienne, le pic de charge se lisse au lieu de tomber au même instant. C'est la fonctionnalité que tous les administrateurs de flottes finissent par re-bricoler en cron avec un  peu élégant.\r\n\r\nLe logging gratuit dans journald\r\n\r\nTout ce que le service écrit sur stdout et stderr est capturé automatiquement par journald. Une seule commande pour tout consulter :\r\n\r\n\r\n\r\nPas de configuration, pas de redirection à la main, pas de  à coller à chaque ligne de crontab. Et accessoirement, journald gère la rotation, la compression et la rétention.\r\n\r\nLes dépendances déclaratives\r\n\r\nDans le fichier , on peut dire au planificateur qu'un job nécessite que le réseau soit prêt, qu'un point de montage soit présent, qu'un autre service ait démarré :\r\n\r\n\r\n\r\nsystemd attend que ces conditions soient remplies avant de déclencher le service. Le job ne tente plus de s'exécuter sur un montage absent ou avant que la résolution DNS soit fonctionnelle.\r\n\r\nLe contrôle des ressources via cgroups\r\n\r\nPuisque chaque exécution passe par un service, on bénéficie de tout l'arsenal cgroups de systemd :\r\n\r\n\r\n\r\nUn job de sauvegarde qui pourrait saturer le disque ne sortira pas de son enveloppe. Cron n'offre rien d'équivalent — au mieux on enrobe la commande dans  et , ce qui reste primitif.\r\n\r\nLa vue consolidée\r\n\r\n\r\n\r\nUne seule commande, toutes les exécutions planifiées du système, classées par prochaine échéance, avec date de dernière exécution. La question « qu'est-ce qui tourne automatiquement sur cette machine ? » trouve enfin une réponse en une ligne.\r\n\r\nUn exemple complet, pas-à-pas\r\n\r\nReprenons le job de sauvegarde initial —  — et traduisons-le.\r\n\r\n :\r\n\r\n\r\n\r\n :\r\n\r\n\r\n\r\nActivation :\r\n\r\n\r\n\r\nVérifications :\r\n\r\n\r\n\r\nComparé à la ligne de crontab originale, c'est plus verbeux. Mais on a, sans rien ajouter : le rattrapage en cas d'arrêt machine, du jitter pour éviter les pics, l'attente du réseau, des limites de ressources, du logging structuré, et une commande pour tout inspecter.\r\n\r\nQuelques recettes utiles\r\n\r\nTous les jours à 3h sauf le dimanche :\r\n\r\n\r\n\r\nToutes les 15 minutes pendant les heures de bureau :\r\n\r\n\r\n\r\nLe premier lundi de chaque mois à 5h : pas faisable en une seule expression, mais combinable avec une condition  qui vérifie la date et sort si ce n'est pas le bon jour. C'est l'une des rares zones où cron reste plus naturel ( +  dans le script).\r\n\r\nToutes les six heures à partir du dernier passage (jamais de chevauchement) :\r\n\r\n\r\n\r\nTimer utilisateur, sans  : dans , puis :\r\n\r\n\r\n\r\nQuand garder cron\r\n\r\nTout n'est pas à migrer. Cron reste le bon choix dans plusieurs cas :\r\nScripts portables vers BSD, macOS, ou des conteneurs minimaux. systemd n'existe pas dans Alpine Linux, sur les BSD, ni dans la plupart des images Docker légères.\r\nTâches utilisateur très simples sur un serveur partagé, où chaque utilisateur gère sa propre crontab sans privilèges admin.\r\nNotification par mail intégrée : si  suivi d'une sortie sur stderr couvre déjà le besoin de monitoring, repasser par journald + un exporter Prometheus est de la sur-ingénierie.\r\nUn job de trente secondes à ajouter sur un serveur existant déjà couvert par cron. Mélanger les deux outils est sans risque — ils coexistent sans interférence — et créer deux fichiers pour un alias unique d'une ligne reste excessif.\r\n\r\nLa meilleure stratégie est rarement migratoire au pas de charge. Elle consiste à utiliser systemd pour toute nouvelle tâche planifiée, et à ne migrer les jobs cron existants que quand ils posent un problème concret : un job raté qu'il fallait rattraper, un log perdu qu'il fallait retrouver, un chevauchement qui a corrompu des données.\r\n\r\nEn résumé\r\n\r\nCron n'est pas obsolète, il est sous-dimensionné pour des besoins modernes. Les timers systemd ne remplacent pas la simplicité d'une ligne de crontab pour un job trivial, mais ils apportent à peu près tout ce qui manque dès qu'une tâche planifiée devient critique : rattrapage, logging, dépendances, isolation, observabilité.\r\n\r\nPour un DevOps qui construit aujourd'hui un nouveau service, le choix par défaut a basculé : commencer en systemd, et n'utiliser cron que par exception justifiée. La verbosité initiale des deux fichiers se rentabilise au premier incident de production qu'on diagnostique en  au lieu de fouiller dans des logs disparates.\r\n\r\nEt même sans migrer quoi que ce soit, la commande  mérite d'entrer dans le réflexe de tout audit de machine Linux. C'est là que se cache la moitié des tâches planifiées qu'on croit avoir comprises."},{"uuid":"fcf72b01-aa87-4ec4-9d33-6199d653bc95","slug":"2024-05-13-3d-modular-systems","title":"3D Modular Systems, c'est fini","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2024-07-05 17:39:13","created_at":"2024-07-05 17:39:13","updated_at":"2024-07-05 17:39:13","tags":[],"plain":"3D Modular Systems était une société spécialisée dans la conception et fabrication d’imprimantes 3D évolutives. Leur vision était de vous proposer des imprimantes que vous pourriez faire évoluer, tel un ordinateur auquel on ajoute un composant (disque dur, mémoire vive etc). http://www.3dmodularsystems.com/ 3D Modular Systems est liquidé depuis septembre 2020"},{"uuid":"60c9de09-75b7-45ae-aed7-ff86e8c5cbd4","slug":"system","title":"Administration système","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-15 22:02:32","created_at":"2023-02-15 22:02:32","updated_at":"2023-02-15 22:02:32","tags":[],"plain":"Cette sous-catégorie inclus des articles sur l'administration système de Linux, la gestion des utilisateurs et des groupes, la gestion de stockage, la sauvegarde et la récupération, etc Table des matières\nLes pages\n<nav stacked=\"true\"  fade=\"true\"> </nav> Les sous-catégories\n<nav stacked=\"true\"  fade=\"true\"> </nav>"},{"uuid":"6e3e231f-a4a7-4491-b3e6-e6e6e48a362e","slug":"sgbd","title":"SGBD - Système de gestion de base de données","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-10 22:48:50","created_at":"2023-02-10 22:48:50","updated_at":"2023-02-10 22:48:50","tags":[],"plain":"les SGBD connus\nPostgreSQL | PostgreSQL est la base de données à utiliser pour les gros projets. Stable et très puissant, il permet de gérer des Go de données sans problème. | |\n------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\nMySQL | Mysql est l'un des SGBD les plus utilisés au monde. Il est gratuit et très puissant. Il possède la double licence GPL et propriétaire depuis son rachat par Sun Microsystem eux-mêmes racheté par Oracle (concurrent direct de MySQL). Le logiciel reste cependant entièrement gratuit et libre. Il répond à une logique client/serveur , c'est à dire que plusieurs clients (ordinateurs distants) peuvent se connecter sur un seul serveur qui héberge les données. | |\nMariaDB | Le créateur de MySQL a crée MariaDB suite au rachat de MySQL pour continuer le projet en open source. | |\nSQLite | SQLite est une bibliothèque écrite en C . SQLite est parfait pour les petits projets. Sa particularité est d'être intégré directement à un programme et ne répond donc pas à la logique client-serveur. Il est le moteur de base de données le plus distribué au monde puisqu’il est intégré à de nombreux logiciels grand public comme FireFox, Skype, Adobe, etc. Le logiciel pèse moins de 300 ko et peut donc être intégré à des projets tournant sur de petites supports comme les smartphones. Souvent aucune installation n'est nécessaire pour l'utiliser. | |\nOracle | Oracle Database est sous licence propriétaire, c'est à dire payant. Il est souvent utilisé pour les projets à gros budget nécessitant de réaliser des actions complexes. | |\nMicrosoft SQL Server | Produit Microsoft, sous licence propriétaire. Une version \"Express\" est distribuée gratuitement sur Windows et Linux. Avec des performances et caractéristiques moindre que les versions Entreprise. | | Il y a également DB2, mongoDB, Sybase,Firebird, cassandra, MS Access...\nLequel choisir ?\nIl existe toujours des faux débats pour savoir quelle technologie est meilleure que l'autre. Mais souvent, ces débats n'ont aucun sens. On préférera MySQL pour des projet plus modestes où le nombre d'utilisateurs est faible avec un petit volume de données. Sinon, PostGreSQL est une bonne solution car elle est robuste, efficace et reconnu par des professionnels."}]