Herman BRULE est l’auteur et le mainteneur de deux applications (libres sous licence GPL v3, mais aussi proposées dans des versions payantes « Ultimate ») : l’utilitaire Ultracopier et le jeu CatchChallenger.
Sommaire
Bonjour Herman, peux-tu te présenter ?
Bonjour !
Sur le plan professionnel, je suis DG de Confiared (hébergement Web et VPS) et de Confiabits (fabrication et assemblage de circuits imprimés), et directeur de la technologie chez CTO chez DanSolutions (FAI).
Par ailleurs, j’aide des associations locales (j’habite en Bolivie) dans des domaines techniques comme les télécoms ou le développement logiciel, j’interviens parfois comme conférencier sur ces sujets.
Enfin, je participe au conseil d’administration de la section bolivienne de l’Internet Society (ISOC Bolivie).
Peux-tu nous raconter ton parcours ?
J’ai étudié l’électronique (BTS STI), puis le développement web. J’étais d’ailleurs encore étudiant quand j’ai commencé à développer Ultracopier.
J’ai longtemps travaillé dans l’e-commerce, puis pour des raisons personnelles je suis allé vivre en Bolivie.
J’ai été plutôt déçu par la qualité des offres locales, ici en Bolivie, dans le secteur des technologies de l’information, c’est pourquoi j’ai décidé de proposer mes services.
Peux-tu nous parler de ces deux logiciels ?
Ultracopier
Comment est né ce projet ?
J’avais besoin d’un utilitaire avancé pour la copie de fichiers, comme Supercopier, pour une utilisation sous Linux mais ce dernier n’était pas disponible sur cette plateforme.
Ultracopier est donc né non pas comme un fork de Supercopier mais comme un projet indépendant : à l’époque, Supercopier était écrit en Pascal, et je préférais écrire en C++.
Au final, quand toutes les fonctionnalités ont été implémentées et qu’Ultracopier a disposé d’un skin Supercopier, une redirection a été mise en place.
Aujourd’hui, après 20 ans, le projet est toujours actif et maintenu, malgré les problèmes de tentative de piratage, bug, DDOS, et les évolutions technologiques.
Quels sont les points marquants qui ont, selon toi, marqué son développement ?
Après la reprise de Supercopier, qui a permis de fédérer sa base d’utilisateurs autour d’Ultracopier, il y a eu de nouvelles fonctionnalités au fil du temps :
- la prise en charge de gros volumes (>5TB >10 millions de fichiers)
- les extensions (plugins) et thèmes graphiques (skins), dont le développement m’a poussé à standardiser l’interface pour la réutilisation par des applis tierces.
Quel est le modèle économique ?
C’est assez peu connu mais Ultracopier est proposé dans deux versions : une gratuite (installable depuis le gestionnaire de paquets d’Ubuntu notamment) et une version « Ultimate ». Cette version, payante, est enrichie de fonctionnalités comme
- la mise en pause,
- la limitation du taux de transfert,
- d’autres options de performance selon le système d’exploitation utilisé et inclut un support technique.
Pour être honnête, les utilisateurs de la version payante sont très peu nombreux : une écrasante majorité utilisent la version gratuite et d’autres piratent la version payante.
Ma vie professionnelle et mon engagement à l’ISOC Bolivie sont très chronophages, je ne compte pas mes heures sur mes principales activités d’hébergeur et de FAI, et à une usine de fabrication d’équipements réseau pour ces besoins.
J’ai quand même publié de l’open source comme le firmware OpenWRT pour le routeur wifi 6 que je fabrique.
Des dons ou des achats sont bienvenus pour que je puisse me concentrer davantage à l’open source ;) Je crois que beaucoup de développeurs open source sont dans cette problématique.
Heureusement, l’hébergement ne coûte presque rien car j’utilise mon propre service, et je suis le seul contributeur.
Quelles sont les fonctionnalités les plus attendues que tu penses implémenter ?
Je souhaiterais améliorer l’intégration d’Ultracopier dans les gestionnaires de fichiers sous Linux ou MacOs, mais ce n’est pas chose facile. Pendant des années j’ai essayé de faire modifier les gestionnaires de fichiers pour avoir la possibilité de replacer le copier/coller par Ultracopier. Rien. Soit je suis ignoré, soit je suis refusé (motif de refus récurent : je devrais refaire Ultracopier en « natif » : GTK, KIO, Haiku…), je me vois mal maintenir divers UI. Les votes sur demande de fonctionnalités sont les bienvenus, par exemple ici pour KDE/Plasma.
Je veux aussi implémenter un moteur async natif sous linux (en utilisant io_uring) pour de meilleures performances.
As-tu eu des échanges/retours avec les autres logiciels ou éditeurs (communauté linux / autres éditeurs) ?
Non. J’ai essayé de faire que le protocole d’envoi de copie/déplacement à un logiciel tiers soit un standard avec un protocole commun pour motiver les gestionnaires de fichiers à l’utiliser, je n’ai reçu que des réponses négatives :/
Peux-tu partager des souvenirs marquants de cette expérience ?
Durant toutes ces années, conscient que la copie de données est un sujet qui peut être très sensible, j’ai veillé à être réactif aux retours des utilisateurs : dès que quelque chose d’anormal m’est reporté, je m’assure de vérifier/corriger et de publier très rapidement. Je pense qu’Ultracopier garantit bien l’intégrité des données lors des copies, parfois mieux que des copies par l’outil du système. Par exemple, si pendant le déplacement de fichiers vers un lecteur réseau ce lecteur réseau se déconnecte, alors Windows peut détruire la source sans avoir pu valider l’intégrité réelle du fichier cible. Il faut reproduire un contexte très particulier, mais ça c’est vu.
Malgré cette attention, il m’est arrivé de recevoir des insultes de certains utilisateurs, allant jusqu’à des menaces de mort. J’ai une bonne collection de conversations de ce genre ! Il s’agit d’une minorité d’utilisateurs, en majorité des débutants en informatique et qui n’ont pas utilisé correctement l’outil, ou plus généralement leur ordinateur.
Par ailleurs, le spam et les tentatives de piratage (dont une pour rediriger les paiements des versions "Ultimate » !) auront eu raison des pages Wiki et Maintenance du site, faute de temps pour la modération.
Il me semble tout de même que la majorité silencieuse (= celle qui dit rarement merci ;) ) est dans l’ensemble très satisfaite des services rendus par Ultracopier, et cela est motivant. Pour moi, le point le plus positif est surtout l’acquis de connaissances.
CatchChallenger
Quelle est l’origine de ce jeu ?
Je cherchais à me familiariser avec la programmation autour de sujets relatifs aux clients/serveurs, comme les protocoles, la haute performance, le chiffrement, et aussi les bots… …et le développement d’un jeu est le moyen ludique par excellence !
Vu qu’il n’y a pas de temps réel, je peux jouer avec TOR/I2P (un bon moyen de tester la sécurité), pas de flottant donc cela marche sur tous les CPU, y compris ceux de plus de trente ans et les architectures exotiques comme celles que l’on trouve dans les routeurs (MIPS…).
C’est un mix de plusieurs jeux au gameplay de type crafting (à la lineage/X3/minecraft) qui m’intéressait pour les techniques ce que ce genre implique.
Quels sont les points marquants qui ont, selon toi, marqué son évolution ?
Version 1 : j’ai essayé de m’éloigner visuellement d’un jeu bien connu auquel mon jeu pouvait être associé.
Version 2 : j’ai abandonné Qt niveau serveur car trop lent niveau SLOT/SIGNAL, et revu le thème graphique avec des couleurs plus chaudes, même si ça me rapproche d’un autre jeu connu.
Version 3 : modularité/API et interface responsive, refonte du datapack.
Est-il facile de monter son propre serveur? Ou de modifier le jeu ?
Le client intègre un serveur embarqué pour jouer en solo, qui peut être ouvert sur un réseau local ou sur Internet.
Le serveur a une interface graphique et une version console (avec diverses bases de donnée supportées, y compris du noSQL)
Le datapack est facilement interchangeable et tout est fait pour qu’un enfant puisse le modifier (png, xml, tmx, opus)
Y a-t-il d’autres contributeurs ?
Non
y a-t-il des fonctionnalités importantes qui ne seront pas développées, et pourquoi ?
Il y en a beaucoup, par manque de temps. Je n’ai jamais atteint un stade de maturité sur le jeu de base qui me convient, donc je me concentre là-dessus. Par exemple, je me suis lancé sur le multithreading GPU côté serveur : j’ai pu lancer des tests sur GPU, cela fonctionne bien mais complexifie trop le développement sans apporter un réel bénéfice.
Quel est le rapport avec tes autres projets ?
Avec ce projet, j’ai vite eu besoin d’un grand nombre de VPS, cela m’a incité à m’intéresser aux datacentres et à monter modestement mon premier datacentre. De fil en aiguille, j’en ai fait mon activité :)
J’ai aussi eu besoin de connexions, de haute performance et de haute disponibilité. Curieux, je me suis lancé dans la conception de mon hardware : onduleur, alimentation solaire…
Qu’as-tu retiré de ce projet ?
J’ai été surpris par les performances, pour un code qui n’est pas en assembleur et qui pourrait encore être optimisé : des millions de joueurs sur un CPU de bureau par serveur. Vous saturez l’écran de bots bien avant de saturer le CPU, même un très vieux CPU ou un microcontrôleur de routeur, et la charge en RAM ne dépasse pas quelques Mo.
La prédiction côté client (Client-side prediction), les instructions préparées (SQL parameterized statement) sont très efficaces, je charge tout en RAM sous forme d’entier <=32Bits. Vu qu’il faut des performances bien supérieures du client pour surcharger un serveur, il y a peu de chance qu’on m’attaque via DDOS.
Quels conseils avec le recul donnerais-tu à ceux qui entreprendraient de se lancer ?
Ne faites pas de projets que vous n’allez pas maintenir, aussi bien pour vous que pour ceux qui vont les utiliser.
Aussi, ne vous lancez pas sur un projet que mille autres personnes ont déjà fait avant vous, il y a une tonne de projets de niche qui n’ont pas de solution open source !
Ton rapport au libre
Au niveau personnel, quels logiciels libres utilisez-vous, sur quel OS ?
J’utilise Gentoo Linux et presque que du libre.
Même question au niveau professionnel ?
En général j’essaie de faire le modèle pro suivant : quand un logiciel a été rentabilisé, je le libère.
Niveau data center, on fonctionne en IPv6 avec des logiciels de conversion pour, par exemple, passer de HTTP IPv4 à IPv6, si tu ajoutes tous les services internes + gestionnaires, ça fait mal pas de logiciels.
Niveau industrie, je produis des onduleurs, des serveurs, des routeurs datacentres et domestiques (wifi 6 OpenWRT), avec les difficultés ici pour importer je dois faire avec ce que je trouve sur place (et il n’y a quasiment rien pour la microélectronique).
Niveau FAI, rien à voir avec ce qu’il y a en France, entre les blocages politiques et administratifs (j’attends certaines autorisations depuis de nombreuses années), les monopoles… rien n’avance. Mais malgré ces difficultés j’ai pu innover et proposer des solutions efficaces pour des communautés locales, grâce à des logiciels libres.
Merci pour ce partage, et pour ton apport au libre ! Nous te souhaitons beaucoup de succès dans tes nombreux projets pour 2025 !
Aller plus loin
- Ultracopier (156 clics)
- Ultracopier (Wikipedia) (88 clics)
- CatchChallenger (285 clics)
# crypto
Posté par Psychofox (Mastodon) . Évalué à 1 (+3/-5). Dernière modification le 02 janvier 2025 à 16:18.
Il avait prétendu il y a quelques années que nombreux de ses utilisateurs étaient pour le minage des cryptos comme source de financement des logiciels…alors qu'il avait retiré la fonctionnalité face au tollé que ça avait provoqué.
https://next.ink/8200/106204-ultracopier-raisons-abandon-dun-mineur-crypto-monnaie/
[^] # Re: crypto
Posté par Julien Jorge (site web personnel) . Évalué à 10 (+9/-0). Dernière modification le 03 janvier 2025 à 08:21.
Ça ne me semble pas exclusif et tu fais de gros raccourcis. D'après le lien que tu donnes une partie de ses utilisateurs étaient OK pour financer leur version Ultimate via du temps GPU pour miner tandis qu'une autre partie de ses utilisateurs lui ont reproché de contribuer aux crypto-monnaies. Visiblement ces derniers l'ont emporté sur les premiers. Mais il faut aussi considérer le contexte politique qui l'encourageait aussi à stopper les cryptos, et des soucis techniques comme le fait que l'application était flaguée comme dangereuse par les anti-virus.
Si j'ai bien compris le minage était d'ailleurs en opt-in et était donc sans effet pour les utilisateurs en général, qui râlaient donc pour raisons de principes.
Moi ça me va bien qu'il n'y ait plus de crypto-monnaie mais on ne peut pas limiter la décision uniquement à ce point, et on peut aussi éviter de taper sur les gens.
[^] # Re: crypto
Posté par Psychofox (Mastodon) . Évalué à -1 (+0/-4).
On dit exactement la même chose.
Qui tape sur qui?
[^] # Re: crypto
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Non, tu insinue qu'il ment quand il dit que des utilisateurs étaient pour rétribuer par ce biais.
Toi tu porte des insinuations sur cette personne.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: crypto
Posté par Psychofox (Mastodon) . Évalué à -5 (+0/-8). Dernière modification le 03 janvier 2025 à 15:24.
Où ai-je parlé de mentir?
source: https://www.larousse.fr/dictionnaires/francais/pr%C3%A9tendre/63813
Non. J'ajoute de l'information par soucis d'exhaustivité.
[^] # Re: crypto
Posté par barmic 🦦 . Évalué à 2 (+2/-2).
Présente le comme ça t'arrange ton commentaire n'avait rien de neutre sur le sujet.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: crypto
Posté par Psychofox (Mastodon) . Évalué à -3 (+0/-6). Dernière modification le 05 janvier 2025 à 10:01.
Du coup c'est mal d'ajouter de la perspective?
Je ne crois pas avoir lu une éloge postume mais un entretien.
[^] # Re: crypto
Posté par Julien Jorge (site web personnel) . Évalué à 6 (+4/-0).
C'est mal de résumer une source au point d'en tordre le sens, de sous-entendre une malhonnêteté ou l'ignorance en formulant « il a prétendu un truc alors que… », de faire tout cela en prétextant un souci d'exhaustivité (une exhaustivité qui omet une grosse partie de l'info) ou d'ajout de perspective, et c'est mal de balayer d'un revers de main les commentaires qui te sont faits par la suite.
[^] # Re: crypto
Posté par Psychofox (Mastodon) . Évalué à -3 (+0/-6).
Ben c'est vrai qu'il a prétendu que ses utilisateurs lui demandaient la fonctionnalité. Où est l'erreur là?
# alternative
Posté par Sapristi . Évalué à 3 (+3/-0).
Après des années de lecture linuxfr en anonyme je finis par m'inscrire pour réagir à l'utilitaire Ultracopier.
Aujourd'hui avec la popularisation des SSD NVME qui lisent/écrivent actuellement entre 4go/s et 10go/s, la simple action de copie d'un fichier est devenue incroyablement inefficace avec les gestionnaires par défaut sous Linux et Windows et même les commands gnu de base :
- alternance de lecture/bufferisation puis écriture
- buffers trop faibles
- lecture/écriture via le cache système ce qui est une énorme limitation des débits gargantuesques que permettent les SSD actuels
Du coup j'en ai eu marre et ai développé une sorte d'alternative à la commande cp (les modos censurez moi si l'auto-promo est interdite) qui est également multi-threadée et avec la possibilité d'écriture directe pour ceux que ça intéresse : https://gitlab.com/Tulux/cpfast.
Personnellement je trouve ça très satisfaisant, en plus du gain de temps, de copier de gros fichiers aux limites de ce que permet le matériel que j'ai acheté. Sans l'avoir essayé je suppose que l'auteur d'Ultracopier a dû faire face au même constat et je serai bien curieux d'avoir un retour de sa part.
[^] # Re: alternative
Posté par Zorro (site web personnel) . Évalué à 3 (+2/-0).
C'est marrant, je me faisais exactement la même réflexion récemment… On dirait que l'OS "réfléchit", calcule, quand on fait des copies, il génère une fenêtre pour dire ce qu'il fait, il met une icône qui tourne, des trucs comme ça… Windows peut même afficher la vitesse, avec une courbe et tout… En fait, ça va plus vite de faire un transfert réseau depuis un serveur à l'autre bout de la planète que de copier entre 2 dossiers sur un même support. Si en plus t'as le malheur que le fichier soit en prévisu dans une fenêtre ailleurs, alors là, c'est la cata.
Il paraît que tout est plus performant qu'avant, pourtant. Les systèmes de fichiers, les contrôleurs, les mémoires… Je sais pas, on n'est quand même plus en FAT16 avec des disques magnétiques à 2000 tours/minutes, quand même.
[^] # Re: alternative
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
T'as mesuré? Parce que ce n'est pas du tout mon expérience.
[^] # Re: alternative
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Ce serait intéressant de voir le point de vu de l'équipe de coreutils, ils peuvent peut être reporter certaines de tes optimisations ou options.
Je ne suis pas très clair sur ce que c'est. Pour moi le cache système est quelque chose de transparent. Le système mets en cache ce qu'il lit depuis le disque et le réutilise s'il en a besoin.
Ça c'est bien que sur NVMe si j'ai bien compris. Pour un disque SSD en SATA tu n'a pas de multiples queues utilisables pour lire/écrire. C'est le genre de choses avec les quelles un outils qui se destine à un usage généraliste doit pouvoir gérer (moi j'ai pas encore de NVMe
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: alternative
Posté par Sapristi . Évalué à 1 (+1/-0).
Je sais que récemment ils ont augmenté la taille du buffer de cp parce qu'un certain nombre de personnes avaient fait le même constat. En ce qui concerne les autres changements comme le multi-thread avec ring buffer ou l'écriture O_DIRECT, je pense que ça dénaturerait probablement la philosophie kiss de la commande ainsi que son comportement sachant que l'on parle d'une commande utilisée quotidiennement par un nombre incalculable de personnes.
En effet, lors d'une lecture/écriture les données sont cachées en pages mémoire par le scheduler IO pour potentiellement s'économiser en cas de lecture ultérieure comme tu le décris. Or cette mise en cache est un goulot d'étranglement à ces débits, sur ma machine de test la mise en cache me limite à environ 2-3Go/s avec de la DDR5-5200 stock.
Le driver du fs a également un rôle non négligeable (j'ai des différences en bench entre du ext4 et du exfat à la faveur de ce dernier aussi étonnant que cela puisse paraître).
Dans le cas où la source et la destination sont sur le même périphérique, en effet bien qu'il me semble qu'il est possible de faire un semblant de multi-queues en SATA avec NCQ mais je ne connais assez mal ce protocole et de toute façon les SSDs performants ne sont plus SATA depuis longtemps.
Toutefois il faut bien en avoir de tête que beaucoup de copies se font entre 2 périphériques, ainsi paralléliser les 2 opérations est bien plus intéressant que de les séquentialiser et d'avoir un effet de montagnes russes, sous réserve que les vitesses de lecture et écriture soient à peu près similaires évidemment.
Dans tous les cas, qui peut le plus peut le moins mais il est vrai que pour du HDD plafonnant aujourd'hui à 300mo/s les outils historiques suffisent.
[^] # Re: alternative
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
Et avec io_uring ?
"La première sécurité est la liberté"
[^] # Re: alternative
Posté par Sapristi . Évalué à 1 (+1/-0).
C'est dans les tuyaux ! J'ai prévu de le recetter de mon côté lorsque j'aurais du temps mais plusieurs inconvénients :
- API low level donc plus complexe à utiliser
- spécifique à Linux or je souhaite que mon utilitaire fonctionne également sous Windows
Par ailleurs, mon implémentation, user space donc, consomme déjà très peu de CPU donc je ne sais pas si l'usage d'une API kernel space permettra un gain significatif. En revanche je suis obligé d'utiliser des buffers assez importants pour rendre AIO efficace et j'ai l'espoir que io_uring permette de revenir à des tailles plus correctes.
[^] # Re: alternative
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Quelle est la technique pour l'évier du coup ?
J'en suis pas particulièrement convaincu je t'avoue.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: alternative
Posté par BAud (site web personnel) . Évalué à 4 (+3/-1).
tu enlèves la bonde ;-)
[^] # Re: alternative
Posté par Sapristi . Évalué à 1 (+1/-0).
Écriture directe (O_DIRECT).
En usage particulier il y a par exemple le cas de ceux qui font des sauvegardes sur des disques externes, ou bien des transferts de gros fichiers type films/séries de SDD externe à SDD interne.
En usage professionnel il y a par exemple le transfert chaud/froid local (ex: duplication de VMs) sachant qu'il est courant de jongler entre plusieurs disques ou plusieurs raids. Pour information, ce dernier cas est celui qui a motivé le développement de l'outil avec un gain de temps environ x2-x3.
[^] # Re: alternative
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Tu élimine le cache de lecture via une écriture en directe ? J'imagine que c'est que le noyau tente de mettre en cache le fichier nouvellement créé.
J'ai pas l'impression que les périphériques amovibles soient encore tant utilisés (hors cas très ponctuel). Ceux qui s'achetaient des disques externes pour faire des sauvegardes ont l'air d'être passé au NAS.
Les fois où j'ai vu ce genre d'usages il y avait soit un NFS soit un autre protocole réseau impliqué.
Si c'est pour faire une petite copie local j'utilise généralement du CoW et j'ai pas de problème de performance.
Mais je comprends que pour quels usages il est fait.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: alternative
Posté par Sapristi . Évalué à 2 (+2/-0).
Il y a un cache pour la source et un cache pour la destination, il est possible de désactiver l'un, l'autre ou les 2. Le noyau cache chaque donnée ayant été accédée qu'elle soit lue ou écrite.
Je pense que c'est un biais des milieux techniques, la large majorité des utilisateurs savent à peine ce qu'est un NAS.
La plupart du temps oui (mais pas toujours des fois c'est copié sur un périph froid en local pour libérer le stockage chaud puis dans un second temps synchronisé à distance), toutefois si ton NFS/LUN est hautement performant, ton périphérique local peut être le goulot d'étranglement.
Encore faut-il avoir un FS qui supporte le COW mais effectivement c'est une alternative certainement préférable.
[^] # Re: alternative
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
A ce moment là les utilisateurs ne font pas de sauvegarde. Mais sans avoir de sources (j'en ai pas trouvé), j'ai l'impression que même pour le grand publique, magazines et revendeurs dirigent maintenant ceux qui veulent faire des sauvegardes vers des NAS plutôt que vers des disques externes.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: alternative
Posté par Psychofox (Mastodon) . Évalué à 2 (+0/-1). Dernière modification le 05 janvier 2025 à 09:58.
Non la plupart des gens ne font pas de sauvegarde.
Et un NAS ce n'est pas spécifique aux sauvegardes, pour moi c'est surtout un outil de stockage de données utile pour ne pas à avoir à les copier sur chaque ordinateur et/ou smartphone.
Mes sauvegardes ne sont pas sur mon "NAS" (en fait un vieux laptop avec un disque externe) par exemple mais sur un serveur de sauvegarde. D'ailleurs mon NAS est sauvegardé sur mon serveur de sauvegarde (lui-même repliquant ses données chiffrées sur un stockage s3).
[^] # Re: alternative
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Ok
L'eau ça mouille mais ça n'a rien à voir avec le sujet.
Venir dans une conversation que tu n'a pas suivi pour étaler le fait que tu n'a rien suivi à la conversation
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: alternative
Posté par Psychofox (Mastodon) . Évalué à -6 (+1/-10).
Non j'ai tout lu mais je crois qu'il faut que t'aille péter ou te branler un coup parce que tu as l'air super aigri dans tous tes commentaires depuis 2 jours.
[^] # Re: alternative
Posté par barmic 🦦 . Évalué à 2 (+0/-0). Dernière modification le 05 janvier 2025 à 23:34.
La question n'est pas de savoir à quoi sert un NAS, mais est-ce que les gens font fréquemment des copies sur différents disques au quotidiens. Je ne vois pas ce que viens faire ton serveur de backup là dedans. Que ce soit un serveur de backup, un NAS, S3, glacier ou ce que tu veux le fait qu'il passe par le réseau rend les hypothèses sur la performances des disques caducs.
Ensuite je ne vois pas pourquoi tu me pose un "non" pour ensuite paraphrasé la première phrase de mon commentaire.
Mais n'hésite pas pas à imaginer ce que tu souhaite sur les gens avec qui tu parle c'est plutôt sain.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: alternative
Posté par Psychofox (Mastodon) . Évalué à 1 (+0/-2).
Et la réponse est que statistiquement, non, la majorité ne copie pas grand chose. Casi jamais sur le même disque, à part les pros de la photo de moins en moins sur les supports USB (et encore avec les caméras qui ont maintenant toutes le support wifi), le NAS est un matériel de niche chez les particuliers, c'est surtout du matos utilisé dans les petits bureaux et c'est en perte de vitesse avec la compétition avec office365.
Et force est de constater que même chez des gens qui devraient savoir collaborer avec des stockage en ligne que ce soit sur le réseau local ou cloud, il reste encore une grosse majorité de gens qui utilisent le mail ou les messageries instantanées pour envoyer des fichiers à leurs collaborateurs ou à eux-mėme.
Du coup la performance de la copie avec le gestionnaire de fichier est loin d'ėtre un paramètre important pour la grosse majorité des gen et je comprends que les projets KDE, Gnome ou XFCE n'en fassent pas leur priorité numéro 1.
[^] # Re: alternative
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
L’exagération n'a rien de pertinent ici. Le monde du libre est particulièrement bon pour adresser des sujets de niche. La question c'est la configuration par défaut devrait-elle assumer que l'on copie depuis et vers des périphériques très efficaces au détriment du reste ou rester sur un plafond pour le matériel très efficace.
Faire de l'auto-détection serait très probablement sujet à bug.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: alternative
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
Je suis d'accord.
Cela dit la notion de sujet de niche tiens quand même son importance dans la gestion des priorités. Files, c'est plus de 500 tickets ouverts chez Gnome par exemple à l'heure où j'écrits ces lignes avec des bugs bien plus visibles et gênants pour les utilisateurs qu'une vitesse de la copie qui pourrait être optimisée. J'irai jusqu'à dire qu'un problème d'ergonomie touchera plus de monde et sera plus importante que la copie des fichiers d'un disque nvme vers un autre disque nvme.
[^] # Re: alternative
Posté par Psychofox (Mastodon) . Évalué à 2 (+0/-1). Dernière modification le 04 janvier 2025 à 19:51.
tu copies souvent des trucs dans le même disque? Ça me parait contraire à ce qu'on essaie en général de faire.
Je parle de copie hein, pas de créer un nouveau fichier suite à une compression ou une compilation.
Et au fait il me semble que dans le cas de la copie de fichier sur un même périphérique, ces problèmes de perf ne s'appliquent qu'aux systèmes de fichiers disons…traditionnels. Sur un fs COW (copy on write) tel que BTRFS ou ZFS, copier des fichiers s'apparente un peu à faire des hardlinks, donc les données ne sont pas à proprement dites copiées donc c'est juste une modif de l'index et c'est casi instantané, seuls les blocs qui seront modifié après coup seront écrits lorsque la copie est modifiée, mais du coup pas par cp ou le gestionnaire de fichier.
[^] # Re: alternative
Posté par Psychofox (Mastodon) . Évalué à 2 (+0/-1). Dernière modification le 04 janvier 2025 à 19:56.
Et les systèmes de gestion de containers utilisent les fs overlay et les systèmes de surcouches quand ils ne sont pas sur un système de fichier COW pour éviter de faire des copies. Du coup je ne vois pas bien ce qui reste comme usages de copies sur un même disque.
[^] # Re: alternative
Posté par Sapristi . Évalué à 1 (+1/-0).
De l'instanciation de VM à partir d'une même image par exemple, par ailleurs BTRFS/ZFS sont utilisés à la marge.
[^] # Re: alternative
Posté par DerekSagan . Évalué à 2 (+0/-0).
C'est de niche (d'autant plus que si tu instancies des VM en masse t'as sûrement intérêt à faire plutôt des conteneurs) mais admettons.
Mais du coup si la niche ce sont des énormes fichiers copiés d'un disque vers lui-même je suis étonné de ne trouver ni fallocate() ni sendfile() ni splice() dans ton code mais au contraire le code d'un buffer mémoire (ce que tu dis vouloir éviter en désactivant celui du kernel mais en écrivant le tient en espace utilisateur) qui plus est avec un lock.
T'as fait un bench comparatif ? (j'ai pas trouvé mais j'ai peut être regardé un peu vite: le readme montre les commandes permettant une comparaison mais pas un compte rendu de bench, mais bon j'ai lu vite)
[^] # Re: alternative
Posté par Sapristi . Évalué à 0 (+0/-0).
En effet je ne prétends pas qu'il s'agit d'un usage particulièrement courant mais au moins d'un usage existant.
Comme je disais plus haut, ça peut être de la copie sur un même périphérique ou entre 2 périphériques.
Pour le coup, je ne vois pas trop ce que fallocate() pourrait apporter. Je ne connaissais pas et n'ai pas testé sendfile() ni splice(), merci pour l'info, je bencherai ça dès que j'aurais le temps mais je ne m'attends pas à un gain significatif.
En ce qui concerne le ring buffer, l'idée n'est pas de remplacer les pages mémoires (qui ne sont pas un buffer mais un cache) mais de tricker AIO pour forcer à maximiser la taille des IO et les débiter immédiatement. D'ailleurs les 2 paramètres à savoir taille du buffer et lecture/écriture directe sont paramétrables complètrement indépendamment.
[^] # Re: alternative
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
Mais lancer plusieurs copies avec GNU parallel et en utilisant les options seek/count/skip de dd ne ferait-il pas l'affaire?
[^] # Re: alternative
Posté par Sapristi . Évalué à 1 (+1/-0).
Lancer des copies en parallèle n'a d'intérêt que si AIO le gère de manière optimale ce que mes tests avec fio n'ont pas démontré.
Par ailleurs, il faudrait que tu rajoutes iflag/oflag pour la lecture/écriture directe et bs pour la gestion du buffer qui doit être multiple de la taille de secteur de ton fs en lecture/écriture directe.
Dans l'absolu si on est uniquement sous linux avec un shell et les bonnes commandes, oui on doit pouvoir faire la même chose mais c'est long, peu mémorisable, avec une faible gestion des erreurs etc. D'où l'intérêt d'un utilitaire pour se simplifier la vie, par exemple elle permet aussi de copier une hiérarchie de dossier complète ainsi que de customiser la taille du ring buffer (qui est un multiple du buffer de lecture/écriture) pour compenser les différences de vitesse en lecture/écriture entre 2 périphériques.
Toutefois je ne cherche pas à convaincre qui ce soit, je m'attendais plutôt à des retours techniques de dev confrontés aux mêmes problématiques.
[^] # Re: alternative
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Chalenger pour moi était un moyen de comprendre où est-ce que c'est utile.
Personnellement je pour les rare cas où j'en aurais l'usage, le fais que j'utilise btrfs en perso et XFS sur au boulot fait que le reflog corrige problème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: alternative
Posté par orfenor . Évalué à 2 (+0/-0).
Il y a 25 ans, quand on n'avait que des disques assez lents (3200 tours sans doute) et pas encore de SATA ni d'USB 3, j'ai commis un script Perl pour recopier de façon fiable des grosses hiérarchies de systèmes de fichiers depuis un serveur Linux en prod. À l'époque déjà les outils classiques étaient trop lents (surtout avec un besoin de contrôle) vu le nombre de fichiers (et des besoins spécifiques du client). Les détails sont trop loins, mais c'était nettement plus rapide. Donc oui, sur de gros volumes, shunter le cache noyau et tout le toutim c'est très efficace.
[^] # Re: alternative
Posté par Sapristi . Évalué à 1 (+1/-0).
Sinon VM != conteneur, j'adore les conteneurs mais ce n'est pas toujours utilisable pour tout.
# Entrevue intéressante…
Posté par GuieA_7 (site web personnel) . Évalué à 5 (+3/-0).
…avec une personne au parcours plutôt atypique. Merci du coup !
J'aurai même aimé plus de détails ; par exemple le fait de fabriquer soi-même onduleurs et routeurs me rend curieux.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.