groumly a écrit 3288 commentaires

C'est un moyen comme un autre de régler ses problèmes.

C'est le moyen le plus courant de régler ses problemes dans un domaine ou l'offre est particulierement abondante, effectivement. S'attendre a ce que les utilisateurs fassent le boulot de QA de la distro, ca va 5 minutes.

du japonais en l'occurence. c'est nippon ni mauvais, pour être honnête.

Mais pourquoi donc "non raisonnable".

Faire du support linux sous windows, c'est pas raisonable, systemd ou pas. Tu peux blablater ce que tu veux, c'est un use case a la con.

Quand on travaille en entreprise un tant soit peu sécurisé ou industriel, il y a des protocoles et des contraintes sur ce qu'on peut installer et inter-connecter.

Et il y a aussi des protocoles pour changer ce qui est installe. Et accessoirement, travailler en entreprise un tant soit peu securise ne veut pas necessairement dire avoir des admins nazis

En l'occurence, si c'est rigide que ca chez toi, tes produits ne supportent probablement pas systemd de facon officielle, et donc le probleme ne se pose pas.
D'ou delire, et besoin non raisonnable.

C'est une facon polie de dire que le texte brut n'est jamais utile.
Tout son argumentaire tourne autour de ca.

Edit: le titre est explicite quand meme "grepping logs is terrible"…

Les characteres non ascii sont rare, si t'operes en occident uniquement, certes. Mes logs d'asie/pacifique, ils sont pleins de characteres pas ascii du tout. Et aussi de characteres ascii, parce que mes messages a moi eux sont en anglais. En l'occurence, tout est en utf kekchose, donc on s'en cogne, mais les arguments "le texte est 100% universel", suivi de "nan, mais les bols de riz, les arabes et les feuj, on s'en branle", ca va 5 minutes (et desole pour les langues non latines que j'ai oublie).

Pour l'ebcdic, sans etre un crouton, je me suis bouffe du support ebcdic quand je bossais dans une boite qui gravitait autour du milieu bancaire. La encore - l'argument d'universalite du texte ne tient pas.

Et de toutes facons, l'argument est foireux en premier lieu, vu que tout le monde compresse les logs, tu finit avec du binaire meme si tu logge en plain text.
Et si tu compresses pas, va falloir soit se poser de serieuses question sur tes ops, soit tu logges pas, et la question ne se pose pas vraiment.

Je vous demande juste d'accepter qu'on a pas tous les mêmes besoins et utilisations, et que certains peuvent apporter un éclairage différents sur certaines technologies.

et moi je te demande d'accepter que le besoin que tu as cite au dessus n'est pas raisonnable.
Idem avec ton délire de Red Hat 6.7 sans acces internet.

Sinon, tu t'énerves vachement pour un mec qui souhaite un débat dépassionné.

C'est pas la faute de systemd si tu bosses pour une boite qui t'empeche activement de faire tom boulot non plus,
Si tu fais du support pour linux et qu'ils t'interdisent d'installer les outils linux necessaires a ton taff, comment dire?

Va gueuler aupres de ton boss plutot qu'ici.

Tu peux monter ton disque sur une autre machine, si tu as accès à ta partition, tu peux lire le log. Il est plus compliqué de lire un log binaire à un format particulier dont tu n'es pas spécialiste lorsque l'outil n'existe pas sur le système que tu utilises.

Tu rotate pas tes logs, ni ne les compresse?
Un zip bousille est pas tellement plus utile qu'un binaire journald corrompu. Alors certes, t'as le fichier de log, courant, mais a ce compte la, autant tailer stdout, ca revient au meme.

Apres, si tu parles de desktop, si t'as souvent besoin d'aller fouiller dans tes logs, le probleme c'est pas tant le systeme de logs que le desktop qui visiblement ne marche pas franchement comme il devrait.

La rigidite du schema.
Un truc comme logstash/elastic search, et j'imagine journald (quoque j'ai pas verifie pour etre honnete) te permet d'indexer ce que tu veux comme tu veux, et c'est plutot pratique quand tu recois des logs divers et varies qui ont un nombre arbitraires de champs.
Les donnees sont aussi pas relationnelles du tout, t'auras typiquement une table monstrueuse avec aucune relation/contrainte.

Tu peux eviter la rigidite avec une rdb qui supporte le json (genre postgres), mais on en droit de questionner la pertinence du relationel pour stocker du pur document, sans compter que pg va pas etre jouasse si tu fais que des requete sur le contenu du json. Un format dedie te permet d'extraire l'index en dehors de la partie donnees.
L'idee etant j'imagine que c'est cense marcher aussi bien sur la machine de tata jeanine que sur un container chez facebook qui va se prendre 200 requetes/secondes (encore qu'eux balancent tres probablement leur logs en remote et ont autre chose a foutre que de grepper vm par vm).

Probablement parce que repondre "j'ai jamais entendu dire que journalctl etait pas lent" a un mec qui vient de dire "chez moi journactl est pas lent", c'est un peu chelou quand meme.

Enculeur de mouche, t'as tres bien compris ce que je voulais dire.

en fait à chaque fois que la réponse est sensible, mais pas la question.

Si la reponse est sensible, tu penses pas que le serveur ferait mieux de s'assurer que c'est bien a toi, Kaane, qu'il envoie la reponse?
Comment fait il donc pour s'assurer que la cle publique qu'il est la tienne? Tu lui envoye, ok, mais a ce moment la, comment tu t'assures que tu l'envoyes a la bonne personne?

De plus que tu connaisses le propriétaire de la clef de chiffrement ou non, tu passes quand même de la situation "tout le monde peut intercepter la communication" à "seules les personnes avec la clef privée peuvent intercepter la communication". Ça fait malgré tout une vraie différence.

Ca fait pas de difference si n'importe qui peut t'envoyer sa clef privee a lui et que tu n'as pas de moyen de t'assurer de qui est en face de toi.

plusieurs fois depuis un e-mail signé

et la cle qui a genere la signature, tu l'as recuperee comment (meme question pour le correspondant)? T'as du faire confiance a un tiers pour t'assurer que t'as recupere la bonne cle publique. C'est pas different d'un systeme de CA.
Ou alors t'as fait un echange en personne, mais v'la la scalabilite de la solution.

Tu peux tourner le probleme comme tu veux, le but d'https/tls c'est d'etablir un lien de confiance dans un environement pas de confiance.
A un moment, il va falloir echanger quelque chose, et il va falloir s'assurer qu'on parle bien a la bonne personne. Et evidemment, comme c'est internet, ca se fait tres vite et a tres grande echelle.
Ya un moment ou va falloir faire confiance a quelqu'un pour authentifier la personne a qui on parle. Si t'as une meilleure idee qu'un tiers de confiance, je suis tout ouie.

Tu propose pas d'alternative, tu rales juste la.

Donc je repose la question, ton alternative plus fiable que https, ca serait quoi?

Tu peux pinner une cle publique, plutot qu'un cert, auquel cas tu peux renouveler le cert, sous reserve que t'utilise la meme cle privee pour le regenerer.

Dans ce contexte (appli native), tu peux aussi contourner les CA entierement, vu que tu distribue le cert toi meme avec l'appli.
Reste a distribuer et executer ton appli de facon fiable, et les stores serieux aident a resoudre le probleme.

Apres, est ce que ca marche dans 100% des cas? Non, probablement pas, mais si t'as une solution qui marche dans 100% des cas, je serais ravi de l'entendre.

Pourquoi on s'eloignerais du sujet? une chaine de confiance est necessaire pour quelque chose du genre.

Pour la fiabilite des CA, le ssl pinning aide a resoudre le probleme.
Pour des applis natives, c'est relativement simple a mettre en place, t'embarque la ca dans le binaire et tu rejette toute connexion qui n'est pas signee par ce cert specifique.
Pour les navigateurs, des extensions pourraient permettre d'avoir le meme comportement.

'fin, je sais pas, tu proposerais quoi comme alternative?

La requete montrera pas grand chose, a part une ip.
Ip qui peut etre un proxy vers wikipedia (ou autre chose).

Le chiffrement ne sert strictement a rien si tu ne sais pas a qui appartient la cle avec laquelle tu chiffre.

J'ai du mal a suivre.
Qu'est ce qui est impressionant dans la video?
Le mode fenetre? Le double ecran sur le telephone?

Laisse moi reformuler:
Encore un blaireau qui a tres probablement foutu la grouille dans son init, tout en croyant etre un expert linux parce qu'il a copier/coller un curl | bash depuis les forums ubuntu. Alors certes, ca boote plus vite, mais ca aurait explose en plein vol meme sans systemd de toutes facons, parce qu'il a modifie les init scripts a la truelle.
Mais comme c'est tendance de faire son hipster facon "les vieilles technos c'etait vachement mieux", il a decide de venir passer pour un guignol sur linuxfr en etalant bien son incompetence complete.
Il se fait remballer a juste titre par les 2 du fonds qui suivent, pendant qu'albert, fidele a lui meme, amuse la gallerie en se ridiculisant.

Mieux, non?

La communication de Microsoft recherche tout de même à mettre en avant une partie "open source" de l'activité de Microsoft relativement restreinte,

Ca va quand meme, tu te rends compte du boulot que c'est de liberer les milliards de lignes de code qu'ils ont ecrites ces 30 dernieres annees? Tu crois que ca va se faire du jour au lendemain, meme s'ils avaient effectivement l'intention de tout liberer?

C'est ouf quand meme l'attitude de certains.

Et apres tout ca, yen a encore qui viennent t'expliquer que les script shell de sysv c'est super simple et facile a ecrire ou lire…

Web? T'es sur? On parlerais pas d'internet des fois?

C'est bien une reponse d'ingenieur ca.
Oui, techniquement, t'as raison.

En pratique, le model mental est inverse: tu copies quelque chose vers quelque chose d'autres (donc cp a b), mais tu fait un lien de quelque chose vers autres chose (donc ln b a). C'est un peu le concept du lien.
Ca se reflete bien dans tous le systeme, avec par exemple un ls -l qui t'affiche b -> a.

Le fait que 99% des gens (sondage institut odoimouyé) se gourre une fois sur deux sur l'ordre des parametres de ln mais ne se gourre absolument jamais sur cp ou mv devrait etre un signal assez fort.

La France avait un gros avantage sur les USA pour l'hébergement,

Lol.