Re: [gull] Truc et astuces: Compression: Gagnez du temps avec Zstandard (zstd)
On Fri, Nov 27, 2020 at 01:12:25PM +0100, Frédéric Dumas wrote:
> Bonjour Félix,
>
> J’aimerai répondre à ton mail, parce que personne ne le fait, alors
> qu’il est détaillé et que tu as fait l’effort de partager avec nous
> des infos intéressantes.
C'est gentil!
> Le problème de tout algorithme, c’est sa reconnaissance par une base
> large d’utilisateurs, en dehors de nous-mêmes.
Ce n'est pas si confidentiel: c'est un produit de facebook!
D'ailleurs, je ne serais pas étonné de voir ces librairies implémentées
en javascript, voire directement dans des prochaines versions de
navigateurs.
> Si ton application est l’archivage froid, transparent pour les clients
> finaux, où tes machines compressent/décompressent en interne, et ne
> présentent à l’extérieur que des données décompressées, cet algorithme
> à une valeur d’usage élevée, d’après tes tests.
Aussi.
> > Pour ce que j'ai testé, entre 3 et 8 fois plus rapide (moins gourmand) que
> > gzip, avec un résultat comparable voir meilleur!
>
> Ce que je retiens surtout, c’est la faible charge CPU. Je serai
> curieux de savoir si les mêmes résultats s’observent sur AMD, comme
> sur Intel.
> L’optimisation de l’algorithme pourrait être très lié à une
> implémentation du jeu d’instructions plutôt qu’à une autre. Simple
> hypothèse.
Je viens de refaire le test sur mon vieux ``Raspberry Pi Model B Rev 2''
(BCM2835 ARMv6-compatible gpu_mem=128 -> MemTotal: 377'860 kB)
Une configuration suffisament éloignée d'Intel!?
Avec un tarball ``vite-fait'' de ~60M:
Filename Sizegzip bzip2 xzzstd
tarball.tar 59.78M 27.09M 24.20M 19.00M 24.04M
45.31% 40.48% 31.77% 40.21%
2'49.7818" 5'33.8700" 13'13.9549" 1'10.9800"
decompr. 12.2794" 1'31.1238"18.2540" 7.8507"
Compression: 2.4x gzip, 4.7x bzip2 et 11.2x xz. (ratio comparable à bzip2)
Decompr: 1.6x 11.6x 2.3x.
Allez, pour enfoncer le clou, j'y ai créé (sur mon raspberry-pi), un fichier
hautement compressible de 120Mo, de la manière suivante:
$ man info > info.txt; cat info.txt{,,}{,,}... >info_big.txt
J'ai concatené 39'366x info.txt > info_big.txt. Donc limité à des caractère
alphanumériques sans accent, fabriqué par répetitions.
C'est **hautement** compressible!
Well, mon raspberry-pi à bossé durant 3h24'40" pour produire:
Filename Size gzip bzip2 xz zstd
info_big.txt 121.45M 742.40K 491.98K 19.57K12.82K
0.60% 0.40% 0.01% 0.01%
42.5624" 1h17'9.7551" 8'52.6467" 9.7620"
decompr.10.2850"1'31.7102" 6.1586" 5.8106"
Donc gzip 40", bzip2 1h1/4, xz ~9' et zstd: 9"!!
Je ne résiste pas à l'envie de vous montrer la liste des fichiers:
-rw-r--r-- 1 user user 127349010 nov 27 16:19 info_big.txt
-rw-r--r-- 1 user user 760222 nov 27 19:44 info_big.txt.gz
-rw-r--r-- 1 user user 503789 nov 27 19:44 info_big.txt.bz2
-rw-r--r-- 1 user user 20036 nov 27 19:44 info_big.txt.xz
-rw-r--r-- 1 user user 13127 nov 27 19:44 info_big.txt.zst
triée par taille décroissante...
Ok, il s'agit de cas (très) particuliers, mais bon, dans l'ensemble...
Pour plus d'info, n'hésitez pas à tester vous-même et rapporter ici, si vos
résultat présentent un intéret ou suscitent une interrogation!
https://f-hauri.ch/vrac/ziptest.sh
ou https://f-hauri.ch/vrac/ziptest.sh.txt
(Attention, ce script compresse 2x avec chaque outil: une première fois pour
mesurer le temps, donc l'un après l'autre, sans écrire la sortie et une
seconde fois (tous les algos à la fois**) pour avoir quelque-chose à décom-
presser afin de mesurer le temps de décompression... Ces test sur mon
raspi ont donc pris près de 5h! **Attention à l'espace disponible!!! )
> Si l’application consiste au contraire à distribuer des fichiers à
> l’extérieur, la valeur d’usage de tout nouvel algorithme de
> compression me paraît très faible. A cause de la difficulté à le faire
> adopter par une nouvelle masse critique d’utilisateurs.
A voir...
> A contrario, combien de fois voit-on des archives distribuées sous forme
> de .zip, « parce que ça peut-être ouvert sur n’importe quel ordinateur »,
l'alternative à .zip serait .tar.?z voire .cpio.?z... mais bon, c'est plus
compliqué, il faut utiliser 2 programmes...
> Merci pour ton mail, mais restons conscients que Zstd n’intéresse
> vraisemblablement à grande échelle que les datacenters.
Il me semble opportun de s'interesser à cette librairies pour les applications
de backups, ( type ``partclone'' ) et d'archivage (tarball.tzst)!
Voilà.
Par ailleur, je profite de cette réponse pour apporter des petites précisions
sur les fichier utilisés pour mon premier test.
> > Le 15 nov. 2020 à 15:07, felix a écrit :
> >Filename Sizegzip bzip2
[gull] Compression : Suite
Bonjour tout le monde, Puisque l'on en est à parler compression, voici l'extrait d'un mail que j'ai envoyé à Félix au début septembre. Depuis mes développement (le soir) ont dérivés vers un serveur avec des conteneurs Dockers et la réécriture de quelque chose de plus intelligent que fail2ban (on s'amuse comme on peut). Donc, avec une vitesse d'exécution et un taux de compression bien supérieure à tout ce qui existe, ça devrait en titiller plus d'un :-) Comme je l'ai dit, je vais mettre tout ça en GPL V3, mais j'ai besoin d'un peu de temps pour plusieurs raisons. Si quelqu'un a une idée pour héberger le code quelque part en évitant github, je suis preneur car le développement de mon serveur prend du temps, vu que je veux y associer le développement d'outils de gestion de cluster non-stop et d'autres outils de sécurité. dc /*** Extrait */ Je me suis finalement remis à mon fameux problème de compression de valeurs numériques, et j'ai enfin terminé l'algorithme complet. Je l'ai fait en Python car j'ai fait plein d'essais (je n'ai d'ailleurs pas fini) et Python me laisse beaucoup de liberté pour faire joujou et faire une quantité d'essais... Bref, mon code n'est absolument pas optimisé du tout, c'est même l'horreur car j'avais besoin (et j'ai toujours pour mes nombreux et futures essais) d'imprimer plein de valeurs intermédiaires. J'ai d'ailleurs passablement séché sur le compactage des bits car je n'ai pas arrêté de faire des conneries... Bref, je suis super content du résultat final ! J'ai comparé mon taux de compression et les temps d'exécutions avec les commandes : - compress - gzip - bzip2 - xz J'obtiens le tableau suivant : CommandeTemps Taille ratio nouveau/original compress: 1.19318'659'929 22.5% gzip: 2.00 13'127'832 15.8% bzip2 : 5.34010'084'519 12.1% xz : 36.243 7'288'500 8.8% Et maintenant mon code que j'appelle 'nuc' pour "NUmerical Compress" nuc : 12.702 4'726'559 5.7% Soit un taux de compression de 17.5 (cad compressé à 94.3%) Taux de compression impressionnant... Le temps n'est pas si mal, considérant que c'est du très bête Python interprété et vraiment bourrin. Je vais maintenant faire une version en utilisant NumPy et je devrai peut-être arriver un peu de dessous des temps de bzip2 (toujours pour de l'interprété). Ensuite, je vais passer au codage en C (depuis Python toujours) et je devrais battre même compress les doigts dans le nez (du moins je pense). Qui plus est, mon mode de compactage est massivement plus rapide que les autres quand il s'agit de décompresser. Surtout, je suis dans une configuration de donnée pas forcément très favorable et je devrais arriver aux alentours de 2'500'000 bytes avec une autre config, me donnant un taux de compression 97-98% par rapport au fichier original, tout en étant encore plus rapide. Je ferai des essais ce week-end Voici les 10 premières lignes du fichier d’origine qui fait un peu plus de 83 MB (+2'300'000 lignes): 1590962409.747,1.069640,1.069710,0 1590962409.849,1.069640,1.069700,0 1590962410.249,1.069640,1.069710,0 1590962412.697,1.069660,1.069710,0 1590962412.798,1.069660,1.069720,0 1590962414.58,1.069650,1.069720,0 1590962414.926,1.069650,1.069730,0 1590962415.15,1.069650,1.069720,0 1590962415.432,1.069650,1.069730,0 1590962416.739,1.069650,1.069720,0 ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Truc et astuces: Compression: Gagnez du temps avec Zstandard (zstd)
Bonsoir, Le ven. 27 nov. 2020 à 13:13, Frédéric Dumas a écrit : > > > Zstandard (ou Zstd) est un algorithme de compression de données sans > > > Pour ce que j'ai testé, entre 3 et 8 fois plus rapide (moins gourmand) que > > gzip, avec un résultat comparable voir meilleur! > > Si l’application consiste au contraire à distribuer des fichiers à > l’extérieur, la valeur d’usage de tout nouvel algorithme de compression me > paraît très faible. A cause de la difficulté à le faire adopter par une > nouvelle masse critique d’utilisateurs. A contrario, combien de fois voit-on > des archives distribuées sous forme de .zip, « parce que ça peut-être ouvert > sur n’importe quel ordinateur », n’est-ce pas ? > La distribution brute de fichiers compressés n'est-elle pas devenue une curiosité aujourd'hui? Les fichiers sont aujourd'hui distribués à travers un protocole, par exemple pour les mises à jour (Arch Linux, Debian, Red Hat, Windows, Android). Qui sait quel algorithme de compression est utilisé dans ces différents cas? A part ça, un algorithme de compression rapide est utile dans les protocoles réseaux, comme HTTP. Je viens d'ailleurs de vérifier mes navigateurs, et ils supportent gzip (LZ77), deflate, br (Brotli). Brotli occupe la place qu'aurait pu prendre zstandard. Bonne soirée Marc ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Truc et astuces: Compression: Gagnez du temps avec Zstandard (zstd)
Frédéric, Le problème de tout algorithme, c’est sa reconnaissance par une base large d’utilisateurs, en dehors de nous-mêmes. C'est surtout vrai dans le cas d'un algorithme de cryptage, beaucoup moins dans le cas d'un algorithme de compression dont le code est un logiciel libre et qui ne nécessite aucune configuration particulière. Compte tenu de la chute régulière du prix du Go, le taux de compression est aujourd’hui moins critique (sauf masses de données absolument considérables à archiver). Oui... à condition de ne traiter toujours que la même quantité d'information. Or... c'est très loin d'être le cas. Dans les années 70, un disque de 400KB était déjà extraordinaire. Quelques années plus tard, on se pâmait devant un disque de 5 MB, puis ce fut 64MB, puis 500MB dans la deuxième moitié des années 80. Nous sommes alors entré dans le monde Giga, puis du Tera plus récemment et bientôt les disques de quelques centaines de TB seront monnaie courante. Le nouveau centre météo Européen (en Italie) prévoit de gérer 10PB de données par jour et on se trouve donc à parler d'Exabytes comme quelque chose de courant. 1 Exa c'est 10**18 et 1kilo c'est 10**3... entre les deux, 15 ordres de grandeur et je ne vois aucun signe de ralentissement. Je ne dis pas que c'est bien ou que l'on pourrait faire autrement, je me content de constater. Donc, non, la compression va sans doute devenir un enjeu majeur et partout. J'ai développé un algorithme avec des taux de compression de 97-98% pour des valeurs numériques et des situations particulières. C'est pour l'instant en Python et je dois encore faire une version avec Numpy ainsi qu'une version en C. Je mettrai ce logiciel en GPL V3 et tout le monde pourra l'utiliser sans restriction. Je dois aussi faire des tests sur d'autres types de données, mais j'ai bon espoir d'obtenir de meilleurs résultats que tout ce qui existe. En plus, la vitesse de décompression est imbatable et celle de compression est très bonne (aussi meilleur que bzip2/bzip). Il faut juste que je fasse des tests, que je finisse la version Numpy/C et que je mette tout ça sur un serveur git (sans doute un serveur perso), mais certainement pas sur github ! Si le gain es faible, cela n'intéresse personne, par contre les choses changent à partir d'un certain pourcentage. Ce qui signifie que l'intérêt est là à partir du moment où le jeu en vaut la chandelle. Ce que je retiens surtout, c’est la faible charge CPU. Je serai curieux de savoir si les mêmes résultats s’observent sur AMD, comme sur Intel. L’optimisation de l’algorithme pourrait être très lié à une implémentation du jeu d’instructions plutôt qu’à une autre. Simple hypothèse. Ces codes son écrit en C, donc pas vraiment de révolution d'un CPU à l'autre. Ce que tu dis est vra à partir du moment où l'on peut utiliser des instructions assembleurs spécifiques, mais ce n'est pas le cas avec des compilateurs standards. Par contre, dans le domaine du traitement d'images et de vidéos, il existe des instructions accessible à partir de librairies spécifiques. Si l’application consiste au contraire à distribuer des fichiers à l’extérieur, la valeur d’usage de tout nouvel algorithme de compression me paraît très faible. A cause de la difficulté à le faire adopter par une nouvelle masse critique d’utilisateurs. A contrario, combien de fois voit-on des archives distribuées sous forme de .zip, « parce que ça peut-être ouvert sur n’importe quel ordinateur », n’est-ce pas ? L'adoption se fait d'elle même. Mon expérience m'a montré que les gens s'intéresse à quelque choses de nouveau à partir du moment où le gain est de 20-30% supérieur. C'est vrai pour les performances des CPU, et c'est aussi vrai pour les logiciels. dc ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Samba 4.7.6 - droits sur les fichiers cote client
Bon week-end qui s'annonce à tous, Sur Samba, qui décidément est un ami difficile, je reviens avec une autre question. Quand je copie depuis le serveur SMB un fichier en 640 sur le serveur, il arrive en 700 sur le Mac. Une bonne âme pourrait-elle me dire quel paramètre ai-je mal configuré, pour que les droits sur le serveur diffèrent soudain coté client ? Ou ai-je oublié au contraire de configurer un paramètre, ce qui conduit à l’imposition de droits par défaut absurdes. La gestion des droits, c’est un truc qui me donne régulièrement du fil à retorde. Aussi, je me demande si je ne commence pas à faire une allergie à Samba, et j’appréhende de replonger dans sa documentation. Merci pour votre aide éventuelle. Je la demande à titre humanitaire :-) -- Frédéric Dumas f.du...@ellis.siteparc.fr > Le 21 oct. 2020 à 11:42, Frederic Dumas a écrit : > > > Bonjour à tous, > > Le regard neuf de l'un d'entre vous me serait bien utile, concernant une > config Samba. > > Sur le serveur, un volume est partagé sans authentification, trois volumes > sont partagés sur login. > > Chaque nouvelle machine échoue à se connecter au volume partagé ouvert. C'est > reproductible avec tous les clients, Linux, OS.X et Windows. > > Seuls les clients qui se sont authentifiés au moins une fois sur un des > volumes partagés par login peuvent ensuite accéder sans problème au volume > ouvert. > > Je pensais avoir trouvé la solution avec le drapeau > >map to guest = bad user > > mais ce n'est pas ça. > > Mon but est évidemment d'accorder l'accès directement au volume ouvert; > autrement, il perd son objet. > > > Merci pour vos lumières. > Ci-dessous, copie de la configuration Samba du serveur, si on pouvait y voir > une erreur évidente. Je peux fournir aussi les logs. > > > L'autre hypothèse, c'est que la 4.7.6 est bogguée, comme je l'avais lu dans > le temps. > > https://www.mail-archive.com/gull@forum.linux-gull.ch/msg06598.html > > > -- > Frederic Dumas > f.du...@ellis.siteparc.fr > > > > > [global] > # Basic options > panic action = /usr/share/samba/panic-action %d > server string = Common stuff > max log size = 1000 > client signing = mandatory > log file = /var/log/samba/log.%m > deadtime = 5 > passwd program = /usr/bin/passwd %u > passdb backend = tdbsam > create mode = 770 > sync always = yes > wide links = no > pam password change = yes > passwd chat = *Enter\snew\s*\spassword:* %n\n > *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . > map archive = no > directory mode = 770 > socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY > debug level = 3 > # Security context >map to guest = bad user >smb encrypt = desired >server min protocol = SMB2_10 > # NetBIOS magic stuff > server role = standalone server >security = user >disable netbios = yes > os level = 20 > # OS.X compatibility features - only includes options whose values differ > from the default ones > ea support = yes; default no (for 4.7) > vfs objects = catia fruit streams_xattr > fruit:metadata = stream ;default netatalk > fruit:nfs_aces = no ; default yes > fruit:copyfile = yes; default no > fruit:veto_appledouble = no ; default yes > fruit:encoding = native ; default private > > [PubliBox] >guest only = yes >public = yes >force group = users >comment = Open zone >writeable = yes >path = /home/smb.public > > [PersonalBox] >valid users = smb.me >path = /home/smb.me >comment = your space >writeable = yes >force group = smb.me > > [TeamBox] >comment = team space >writeable = yes >path = /home/smb.team >valid users = smb.me,smb.you,smb.test >force group = smb.team > > [Titles] >valid users = smb.me >path = /home/smb.music >force group = smb.you >comment = music repository >writeable = yes >force user = smb.you > > > > > > > > > ___ > gull mailing list > gull@forum.linux-gull.ch > https://forum.linux-gull.ch/mailman/listinfo/gull ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?
Le 26.11.20 à 14:04, Frédéric Dumas a écrit : >> Arnaud a écrit : >> Personnellement, je suis en train de créer mon propre cloud personnel, >> auto-hébergé chez moi :) > > Tu utiliseras Nextcloud ou autre chose, Arnaud ? Mon but et de créer un mini-datacenter, gestion emails, sites web, tester divers projets, voir créer le mien. Donc nextcloud pourquoi pas, mais la nouvelle machine qui arrive est assez puissante pour ne pas me restreindre à que nextcloud :) Je dois toujours décider de ce que je veux y mettre comme base... J'ai eu plusieurs avis, et je n'arrive pas à me décider, donc il faut que j'en teste plusieurs. Proxmox pourquoi pas (mais c'est debian la base ^^ je peux essayer en tout cas), oVirt, ou autre chose. Cordialement OpenPGP_0xEA0DA251B671CC2A.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Project Manager
Am 27.11.2020 um 14:13 schrieb felix: Bonjour, J'ai une question qui revient régulièrement à propos d'alternatives au M de GAFA ;-) Que peut-on proposer décement pour gérer des projets (suivi, rappels, timeline, diagramme de gantt, etc)... Dans mon mail de hier au sujet d'EGroupware comme outil pour un "cloud privé", je n'ai pas évoqué le module de gestion de projet. Je ne l'utilise pas et ne le connais pas assez, et surtout, je ne sais pas ce que ça vaut face à la concurrence. ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Project Manager
Bonjour On 27/11/2020 14:13, felix wrote: J'ai une question qui revient régulièrement à propos d'alternatives au M de GAFA;-) Que peut-on proposer décement pour gérer des projets (suivi, rappels, timeline, diagramme de gantt, etc)... J'avais essayé taskjuggler il y a très longtemps https://taskjuggler.org/ Il faut bien entendu un peu d'effort pour le prendre en main, mais pour mes modestes besoins, il semblait bien suffisant. Je ne peux pas comparer avec le produit que tu mentionnes, parce que je ne le connais pas. claude ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
[gull] Project Manager
Bonjour, J'ai une question qui revient régulièrement à propos d'alternatives au M de GAFA ;-) Que peut-on proposer décement pour gérer des projets (suivi, rappels, timeline, diagramme de gantt, etc)... -- Félix Hauri -- http://www.f-hauri.ch ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Truc et astuces: Compression: Gagnez du temps avec Zstandard (zstd)
Bonjour Félix, J’aimerai répondre à ton mail, parce que personne ne le fait, alors qu’il est détaillé et que tu as fait l’effort de partager avec nous des infos intéressantes. > - https://fr.wikipedia.org/wiki/Zstandard > Zstandard (ou Zstd) est un algorithme de compression de données sans > perte développé à partir de 2015 par Yann Collet (également connu sous > le pseudonyme « Cyan ») et supporté par Facebook. Il s'agit aussi de > l'implémentation de référence en C de cet algorithme. Le problème de tout algorithme, c’est sa reconnaissance par une base large d’utilisateurs, en dehors de nous-mêmes. Compte tenu de la chute régulière du prix du Go, le taux de compression est aujourd’hui moins critique (sauf masses de données absolument considérables à archiver). Si ton application est l’archivage froid, transparent pour les clients finaux, où tes machines compressent/décompressent en interne, et ne présentent à l’extérieur que des données décompressées, cet algorithme à une valeur d’usage élevée, d’après tes tests. > Pour ce que j'ai testé, entre 3 et 8 fois plus rapide (moins gourmand) que > gzip, avec un résultat comparable voir meilleur! Ce que je retiens surtout, c’est la faible charge CPU. Je serai curieux de savoir si les mêmes résultats s’observent sur AMD, comme sur Intel. L’optimisation de l’algorithme pourrait être très lié à une implémentation du jeu d’instructions plutôt qu’à une autre. Simple hypothèse. Si l’application consiste au contraire à distribuer des fichiers à l’extérieur, la valeur d’usage de tout nouvel algorithme de compression me paraît très faible. A cause de la difficulté à le faire adopter par une nouvelle masse critique d’utilisateurs. A contrario, combien de fois voit-on des archives distribuées sous forme de .zip, « parce que ça peut-être ouvert sur n’importe quel ordinateur », n’est-ce pas ? Merci pour ton mail, mais restons conscients que Zstd n’intéresse vraisemblablement à grande échelle que les datacenters. Bye, Frédéric. -- Frédéric Dumas f.du...@ellis.siteparc.fr > Le 15 nov. 2020 à 15:07, felix a écrit : > > Bonjour, > > Je voulais vous parler d'un outils de (de)compression qui m'a impressionné. > > - https://fr.wikipedia.org/wiki/Zstandard >Zstandard (ou Zstd) est un algorithme de compression de données sans >perte développé à partir de 2015 par Yann Collet (également connu sous >le pseudonyme « Cyan ») et supporté par Facebook. Il s'agit aussi de >l'implémentation de référence en C de cet algorithme. > > Pour ce que j'ai testé, entre 3 et 8 fois plus rapide (moins gourmand) que > gzip, avec un résultat comparable voir meilleur! > > Voici un petit bench, sur une poignée de fichiers ``représentatifs'': > le pus gros: 4Gb: gzip: 138" -> 2.51G, zstd: 17" -> 2.44G (sans multithread). > >Filename Sizegzip bzip2 xz zstd zstd-T4 >wavfile.wav 48.72K 35.02K 33.91K 32.77K34.55K 34.55K > 71.89% 69.60% 67.27%70.91% 70.91% > .0060" .0116" .0293".0028" .0026" >decompr. .0015" .0051" .0053".0015" > >test.svg296.14K 43.65K 40.01K 36.03K45.69K 45.69K > 14.74% 13.51% 12.16%15.43% 15.43% > .0107" .0323" .0741".0039" .0039" >decompr. .0049" .0107" .0070".0021" > >script.tm 1.34M 244.04K178.05K183.69K 272.71K 272.71K > 17.76% 12.96% 13.37%19.85% 19.85% > .0538" .1392" .7947".0123" .0126" >decompr. .0131" .0374" .0234".0055" > >screenshot.png1.86M 1.86M 1.84M 1.85M 1.86M1.86M > 99.93% 98.95% 99.39% 100.00% 100.00% > .0727" .2767" .4964".0088" .0089" >decompr. .0195" .1381" .1031".0034" > >script.log 11.20M 287.64K200.62K165.01K 217.67K 217.67K > 2.51% 1.75% 1.44% 1.90%1.90% > .1061"1.3140"1.0747".0236" .0188" >decompr. .0448" .1186" .0432".0104" > >somesources.tar 372.65M 91.52M 71.53M 57.02M81.61M 81.61M > 24.56% 19.19% 15.30%21.90% 21.90% > 11.1434" 37.0908" 2'9.7232" 1.8509" .8362" >decompr.2.0741" 10.1793"3.8732".5316" > >win10rescu.ntfs 408.52M 384.73M385.64M380.21M 382.04M 382.04M > 94.18% 94.40% 93.07%93.52% 93.52% > 13.2750" 1'2.3206" 2'32.0821".6944" .4324" >de
Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?
Hello ! > Notre optique technique est une base de proxmox avec du Debian par > dessus en KVM et un CentOS pour un FreeIPA (annuaire LDAP/Kerberos). On > utilise en effet ansible (c'est assez génial) et LibreNMS pour la > supervision de l'ensemble, et Gitlab pour développer nos playbooks > ansible. Bref, on peut faire un petit chaton avec une grosse workstation > d'occasion et deux disques en RAID logiciel. J'utilise Proxmox en production depuis presque 10 ans alors je me permets ceci : - Pourquoi utiliser KVM alors que LXC est beaucoup plus efficace ? - Plutôt que du software RAID mdadm, j'utilise désormais ZFS en mirroring. - Je recommande de mettre le système sur 2 SSD NVMe et de garder un espace libre pour y mettre le ZIL et le L2ARC des éventuels HDD. Meilleures amitiés, Jean-Marc Vandel CTO ● Ing. info. dipl. EPFL **Open Net Sàrl ● Odoo Gold Partner** [Rue de Genève 77 ](https://goo.gl/maps/VB68piUM4FARqnv76) 1004 Lausanne VD [www.open-net.ch ](https://www.open-net.ch/) +41 21 701 42 45 ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
