jben a écrit 861 commentaires

N'est-ce pas ?

De toutes façon, moi tant que je n'ai pas les logs ou des infos détaillés, je ne réponds plus. Je lui ai demandé deux fois, et ça ne viens toujours pas. Soit. J'étais pourtant de bonne humeur aujourd'hui.

Cher ami,

Vraisemblablement je suis intervenu pour rien, j'en conviens. Il est toujours aussi désagréable de te lire. Pour que tu t'améliores :

Sur la forme,

• Une capitale est de bon goût pour marquer la majuscule,
• Une espace après la virgule est appréciée,
• + est un opérateur mathématique mal venu dans une phrase, le mot plus est plus approprié.

Sur le fond,

• Je n'ai pas prétendu que j'en savais plus que toi, je précisais qu'il était prétentieux de se définir comme calé quand on vient poser une question. Et je donnais un avis personnel vu la qualité de tes réponses, en aucun cas je comparais ton niveau au mien.

• « j'ais tout éssayé » : Si tu veux qu'on t'aide, ça serait bien de nous dire quoi. Car si tu avais tout essayé, et que rien ne fonctionnait, cela signifiai qu'aucune solution n'existe, et ainsi il n'y aurait guère d’intérêt à venir poser une question ici.

• Tu n'as toujours pas précisé quelle distribution, quelle version. (Mais par contre nous connaissons les supports, cd ou dvd).

• Tu n'as toujours pas donné le type d'erreur et décrit précisément ce qu'il se passe.

Si tu veux de l'aide, sois précis !

Bonjour cher ami,

Je suis calé en informatique et même +

Cela soulève deux remarques.

• Je ne pense pas que tu sois « calé ». Vu ce qui transpire de ton post et de tes commentaires, tu as un intérêt pour la question, c'est déjà pas mal, je suis d'accord, mais se présenter comme tel est d'une prétention tellement importante qu'elle ne donne pas envie de te répondre. De plus quelques (ce n'est pas la majorité, j'en conviens) membres de ce site ont un niveau impressionnant, et la moyenne n'est pas mauvaise du tout, comprends que tu perds en crédibilité avec cette phrase.

• Par contre tu n'es pas « calé » en orthographe et en typographie. Il est désagréable de te lire. Il est pourtant essentiel d'écrire dans un style agréable lorsqu'une réponse est espéré. Donc fait attention à ta manière d'écrire, les réponses n'en seront que plus nombreuses. (nota bene : je n'ai pas dit qu'il ne fallait faire de faute, je n'aurai pas cette prétention vu le nombre de fautes que je fais, il faut juste chercher à les éviter).

D'autres remarques de contenu s'imposent.

• Quand on expose un problème, on l'expose complètement. Tu ne donne aucune information. Par exemple :

  • Quelle distribution as-tu tenté d'installer ?
  • Quelle version ?
  • De quelle manière ?
  • Qu'est-il affiché lors du boot ?
  • As-tu tenté des manipulations, lesquelles ?

Et enfin sur le style :

lol console ou n'importe quoi

Merci d'adopter un langage correct et construit. Nous ne sommes pas dans une cour de récréation d'un école élémentaire.

Mais je vais passer outre, et te répondre.

Normalement linux doit accepter le 64 mais rien n'y est il reconnait rien.
[…]
linux ne reconnaît pas mon cpu comme il faut

As-tu choisi la bonne architecture ? Je suppose que non. Enfin c'est la seule explication que j'ai vu les détails que tu donnes.

Alors voyons voir… sur une machine sans journald

ls /var/log/

Oh merde ! Plus de la moitié de mes logs sont en binaire. Et je suppose qu'il en est ainsi pour une bonne partie des détracteurs de ces formats de logs. Les logs binaires correspondent à au moins un besoin, le fait de ne pas user trop d'espace, et pour cela on utilisait gzip. Pourtant personne n'est monté sur ses grand chevaux pour dire « Compresser les logs c'est mal, on ne peut plus les lire directement », pourtant c'est le même niveau de réflexion.

[Edit: Je sais ma réponse pourrait être mieux à d'autres endroit du thread, mais juste après la définition exact de Plain-text, ça me paraissait pas mal]

/dev/stdout doit être laissé au programme lancé.

Les syntaxes >( ) (respectivement <( )) créent un sous-shell et un déscripteur de fichier, et le stdin (respectivement le stdout) du sous-shell correspond au file descriptor. Je confirme ça marche ce genre de syntaxe fonctionne avec bash et zsh, mais en effet c'est pas POSIX à ma connaissance.

Par exemple si tu tape un echo <(true), tu verra le fd créé (ou plus exactement attribué) par le shell.

En utilisant ce genre de syntaxe, tu peux faire des truc sympa, genre rajouter ça dans le ~/.bashrc de quelqu'un qui a laissé sa session ouverte :

. <( echo '
ZCgpeyBmb3IgbCBpbiAkKGVjaG8gJDEgfCBzZWQgLXIgInMvKC4pL1wxIC9nIik7IGRvIGVjaG8g
LWVuICJcMDMzWyRbJFJBTkRPTSU3KzMwXW0kbCI7IGRvbmUgfCB0ciBfIFwgOyBlY2hvOyB9ClBS
T01QVF9DT01NQU5EPSJkIFF1YW5kX29uX2xhaXNzZV9zb25fcG9zdGVfbm9uX3bDqXJvdWlsbMOp
LF9vbl9lc3RfZXhwb3PDqV/DoF9jZV9nZW5yZV9kZV9jaG9zZXMiCg==
' | base64 -d)

Autre exemple assez marrant, et utile. Pour calculer un condensat sha1 en plein milieu d'un pipeline :

... cmd[n] | tee >(sha1sum>&2) | cmd[n+1] ...

Tout d’abord, je suis fan, et je trouve cela génial.

Par contre il y a des points qui me dérangent dans le format du fichier de sortie.

Déjà, le choix de binaire auto-extractible, je trouve cela inutile, et non usuel, mais soit. Tu propose le format tar, et je t'en remercie. Par contre, ce qui est mal c'est que tu fais le choix du format avec le nom de fichier.

Par exemple, si je veux faire une compression xz à la volée, je hais les fichier temporaires, je suis obligé de faire un:

[terminal 1] $ mkfifo /tmp/truc.tar
[terminal 1] $ cat /tmp/truc.tar | xz > /tmp/truc2.tar.xz ; rm /tmp/truc.tar

et

[terminal 2] $ care -o /tmp/truc.tar some_stuff

Si tu supportais une option du genre format, ayant priorité sur l'extension pour choisir le format, je pourrais faire un truc du genre

[terminal] $ care -f tar -o >( xz > /tmp/truc.tar.xz ) some_stuff

C'est quand même plus élégant !

En plus en travaillant de cette manière (et en documentant) tu n'as même plus à gérer la compression, il faut juste que les utilisateurs apprennent à utiliser leur shell.

Tu pourrais me répondre que procéder ainsi rajoute de la latence et c'est inutilisable, mais c'est juste pour l'exemple. Car en vrai j'utiliserai plutôt un truc du genre

[terminal] $ care -f tar -o >( bufcat | xz > /tmp/truc.tar.xz ) some_stuff

avec bufcat un truc qui envoie stdin sur stdout (énorme!) mais en mettant en cache quand stdin est plus rapide que stdout pour ne pas bloquer le processus émetteur. Je viens de tester avec la méthode fifo et bufcat, ça fonctionne au poil sans latence, xz tourne juste avec un décalage.

On pourrait directement imaginer aussi des truc du genre

[terminal] $ care -f tar -o >( bufcat | gzip | ssh host "cat > care-archive.tar.gz" ) some_stuff

Oui, je sais, ma haine des fichiers temporaires est maladive. Mais globalement je trouve ton programme absolument génial à ce détail près (et aussi à mon incompréhension des autoextractibles, mais ça ne doit pas correspondre à mon usage).

En fait, si mon inteprétation de la section 5.2.3.13 de la RFC4880 est bonne, c'est la confiance en la validité de la clef et non la confiance en la manière de valider du propriétaire de la clef qu'on indique ici.

C'est ce que j'utilise. HMAC avec sha256, c'est à peu près ce que tu décris, sauf que c'est plus standart que la concaténation.

Après une fois que j'obtiens mon hash, je l'exprime sur une base arbitraire (en général en base 62, c'est à dire A-Za-z0-9, mais ce n'est pas obligatoire).

J'ai déjà décris tout cela ici dans un commentaire, je donne aussi mon code dans ce commentaire.

[…] c'est que de nombreux visiteurs de ce sites détestent lire des choses longues, exceptées sur les sujets dont ils ont déjà l'habitude […]

Bien vois tu, ce n'est pas du tout mon ressenti. J'ai déjà ici même testé l'experience d'un journal assez long sur un sujet peu abordé ici (le routage d'itinéraire) et ce journal a été très bien noté. Non, je n'en fais pas une loi générale, mais je le me permets de remmetre en doute la tienne.

[…] je vais aller dans d'autres lieux […]

Nous ne te retiendrons pas.

Pas exemple, un texte sans accents est un propos à éviter.

P.S. : J'utilise pourtant moi-même un clavier qwerty.

Très mauvais exemple.

Le code de la route, concerne (liste non exhaustive) :

• les automobiles,
• les autobus,
• les autobus articulés,
• les véhicules remorqués,
• les cyclomoteurs,
• les cyclistes,
• les (cyclistes) assistés,
• les véhicules agricoles et forestiers,
• les véhicules à traction animale,
• les engins de service hivernal,
• les piétons.

Pour se retrouver dans aucune des catégories que j'ai cité, il faut vraiment le vouloir.

Dans ce cas, il faut vérifier à chaque fois (ou un plugin dans le navigateur) pour vérifier que le javascript qui lit ma clef est toujours le même qu'un référence qui aura été approuvée par la communauté.

Bref on a une solution inutilisable (vérification à chaque fois à la main) ou un truc à installer. Et quite à installer un truc, je préfère installer GnuPG.

Edit : je viens de voir que ça peut servir à faire un plugin pour le navigateur. Dans ce cadre, ça peut être interessant, ce n'est pas le site qui envoi le code. Mais il faut toujours installer un truc… Bref, utiliser GnuPG sur mon client localement me parrait toujours la meilleure solution.

D'autres disent que oui parce qu'ils pensent que l'auteur a droit de regard sur toute réutilisation de son œuvre, et n'a pas pu en user dans ce cas là, ce qui fait qu'il a quelque part été dépossédé de son droit.

C'est vrai, l'auteur a un droit de regard, c'est vrai il n'a pas pu en user. C'est donc des arguments en faveur de la contrefaçon.

En gros tu viens de dire

Le débat porte sur "Peut-on appeler ça du vol". Certains (dont moi) disent que non, [que c'est de la contrefaçon]. D'autres disent que oui parce [c'est de la contrefaçon].

Je retourne bosser,

Il n'y a que le premier paquet qui est concerné par ton filtre, et bien redirigé par vers le bon port.

Pour les autres, ils arrivent toujours sur le port 80 après PREROUTING. En particulier les paquets suivant de la requete si il elle est trop grande, en particulier les ACK de la réponse…

ce n'est pas ma conception de la vie en société. Je n'ai pas envie d'avoir un flic et un avocat sur le dos […] la justice à déjà assez de boulot comme ça

Il semble que tu es mal compris le propos. Ou du moins tu l'as compris différemment de moi.

Le fait de tout ramener sur le terrain légal ne veut pas dire faire des procédures en justice à la chaîne, ça ne veut pas dire ne pas communiquer et ne pas réfléchir, loin de là. Cela signifie qu'il faut décrire les situations selon des termes bien précis et univoques. Pour décrire précisément les situations, de manière non ambiguë, nous avons un contexte disponible, c'est le terrain légal, le vocabulaire juridique, et le monde des contrats.

Au final tout ramener sur le plan légal, c'est juste avoir un vocabulaire commun, des bases communes et une compréhension réciproque. Après ça ne veut pas dire aller en justice, heureusement.

Le gras est de moi :

(Quasiment) toutes les distributions Linux peuvent être installées par clef usb, dans mon cas je n'ai même jamais fait autrement.

Tout d'un coup, même si je ne le suis pas, je me sens vieux.

Ubuntu reste bien la distrib la plus accessible au débutant.

Tout ce qui a été montré ici c'est qu'elle est accessible au débutant. Nous manquons de données pour justifier qu'elle soit la plus accessible.

Tout à fait. Je croyais que le -H était inclu dans le -a. En fait moi je n'utilse pas rsync -a au quotidien, mais des alias défini par mes soins (et je n'utilise plus du tout scp) :

alias rs='rsync -rltHAzyPhh'
alias rsd='rsync -rltHAzyPhh --delete-delay'

De plus quand je fais un déplacement dans le même dossier, le -y fait le boulot, je n'utilise pas cette procédure, mais dans les autres cas, si.

Le problème, c'est que l'auteur de la question ne nous donne aucune précision sur la nature des données, et la nature des modifications. Impossible de savoir si c'est compressible ou non. Impossible de proposer une logique differente ou un outils different en en connaissant si peu.

Je suggère donc à l'auteur du journal de donner toutes les précisions dont il dispose. Que ça soit possible ou non, c'est un problème intellectuel qu'il peut être intéressant d'aborder.

Tu remarquera que ce n'est pas du tout ce que je propose. Là tu parle de faire de la sauvegarde en gardant les version précédentes et en stockant les fichiers identiques via un hard link sur le même fichier. Moi je parle de faire un déplacement dans le répertoire qui est sauvegardé sans retransférer les fichiers.

Juste une astuce, je ne sais pas si elle s'applique à ton problème.

Tu parles de déplacement de fichiers, et dans ce cas rsync refait un transfert du fichier, il n'a pas vu que c'est le même.

Par exemple, un répertoire nommé dossier/, synchronisé sur serveur:dossier/.

Initialement on fait

rsync -a dossier/ serveur:dossier/

Puis un jour on veut faire un déplacement de fichier, on fait :

mv dossier/fichierA dossier/fichierB
rsync -a dossier/ serveur:dossier/

Et là c'est le drame. Il retransfère le fichierB.

L'astuce c'est d'utiliser l'équivalence entre mv a b et ln a b; rm a, mais on va rajouter un rsync entre les deux.

cp -al dossier/fichierA dossier/fichierB
rsync -a dossier/ serveur:dossier/
rm dossier/fichierA
rsync -a --delete dossier/ serveur:dossier/

J'utilise cp -al et non ln, car ça permet de conserver les permissions et de faire le machin recursivement pour un répertoire si c'est un répertoire qui est bougé.

Et comme ça, ça passe très bien, il detecte que fichierA et fichierB sont des hard link, il crée fichierB comme un hard link sur fichierA dans la destination, et à l'étape suivante il supprime fichierA.

Alors je ne sais pas si c'est de ce type de déplacement dont tu parles, mais c'est une astuce à connaître quand on utilise rsync.

Utilise tu la compression du flux avec ssh ssh -XC ou non ssh -X ?

La compression rajoute une charge, très faible sur nos processeurs modernes, qui peut des fois être génante avec du matériel ancien. Par contre ça réduit considérablement la taille du flux.

Moi je ne l'active pas sur un réseau local, mais à travers une connexion ADSL je l'utilise.

Bref si tu ne l'utilise pas, fais l'essai en l'activant, si tu l'utilise, fais l'essai en la désactivant.

Ben prenons un exemple de logotype. Un T, on est purement dans le domaine d'application du png.

Voici l'original :

Et voici ce que ça donne en JPEG (tout le signal est dans la luminance on s'en fout des chrominance, et donc le sous-echantillonage des chrominances n'importe), je présente la version obtenue, ainsi que la difference relative à l'original.

• quantification au seuil de 50 %
• quantification au seuil de 75 %
• quantification au seuil de 94 %

Quant au constat au niveau des tailles, il se passe de commentaires :

jben@ginette /tmp/T $ find . -type f -printf '%s\t%f\n'
1889    c94.jpg
1610    c50.jpg
1673    c75.jpg
595     orig.png

Il y a quoi que tu ne comprends pas dans le fait qu'il y a des pertes ? Qu'on voit qu'elles sont selon la base du DCT dans les bords des lignes, et que le codage entropique de PNG est plus adapté ?

Je ne suis pas pro-PNG, je ne suis pas anti-JPEG. J'essai juste d'être cohérent. Pour enfoncer un clou, j'utilise un marteau. Pour visser un vis, j'utilise un tournevis. Et j'ai l'intime conviction que, dans chaque cas, utiliser l'autre outil serait moins efficace.

Je pense que tu ne comprends pas la probèmatique.

Le JPEG, en gros c'est, découpage en bloc, DCT, quantification, puis codage entropique. (Je passe le passage en luminance-chrominances et sous-échantillonage des chrominances). Les pertes se font dans l'étape de quantification, c'est à dire dans la base de la DCT. Autant ces pertes sont acceptables pour l'œuil quand il s'agit d'éléments continus (comme une photo, oh, justement c'est pour ça qu'il a été créé), qu'elles deviennent visibles dès qu'elle existent, même à un niveau très faible en cas de variation brutal du signal.

Rien qu'une ligne noire sur un fond blanc suffit à montrer les artefacts de la quantification des valeurs après transformation par la DCT.

Après, on peut supprimer la quantification, oh, ben dans ce cas JPEG se réduit à un codage entropique. PNG est prévu pour, c'est dommage de ne pas l'utiliser, en plus il y a un canal alpha.

Je le repète sur un logo avec des trucs genre des applats de couleurs, des lignes, quelque soit le niveau des pertes avec JPEG, elles seront beaucoup trop visibles par rapport au gain apporté.

La graisse est un ajout :

Je parle des gens qui ne font pas de bio, physique ou math, public traditionnel de LaTeX en France.

Ça serait tellement bien si c'était vrai !