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?
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.
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.
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 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?
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.
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 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.
Ce n'est pas inacceptable pour tout le monde pour autant.
C'est inacceptable pour quiconque travaille sur sa machine, la disponibilite de l'os doit etre de 100%.
De plus, existe t'il un système à l'épreuve de cela ?
Non, mais tu noies le poisson. Le fait est que l'erreur est humaine, et que ca arrive de deployer accidentellement une mise a jour qui pete des choses. MS l'a fait, Apple l'a fait aussi, ca reste rarissime, et ils se font gueuler dessus comme du poisson pourri quand ca arrive, parce que c'est pas cense arriver.
Ya une difference avec le mode de fonctionnement de testing/experimental, ou les patchs sont balances quasiment sans tests, et les utilisateurs sont censes les rapporter ces bugs.
Si ta testing te pete a la gueule, on te repond "euh, ben oauis. C'est une testing, ca arrive, on va voir si on peut corriger ca". Si t'insiste pour que ca soit corriger "la, main'nant toussuite", on va t'envoyer chier, a raison, on va te pointer le repo stable.
Si ta stable te pete a la gueule, c'est une faute grave de la part de l'equipe responsable, et ils bossent non stop pour corriger ca.
Si tu comprends pas la difference entre les deux, je sais pas quoi te dire.
Et ? En quoi peut-on reprocher cela à Debian ? C'est un mode de fonctionnement proposé. Libre à chacun d'y adhérer ou non.
En quoi peut on reprocher a debian d'avoir fait ce choix? Peut etre parce que c'est eux qui ont fait ce choix? Que tu soit libre de pas utiliser debian (encore heureux!) ne change pas grand chose aux decisions qu'a fait debian.
Et juste au niveau de la stabilité, parce que niveau obsolescence, essaye d'avoir tous tes paquets dans leur dernière version sur une ubuntu pendant plus de 6 mois, sans installer de PPA, tu m'en diras des nouvelles.
Ben ca peut vouloir dire 2 chose:
- soit une distro qui dure plus de 6 mois est une mauvaise idee
- soit le concept de repo central est pas aussi genial que certain le laissent entendre, et ramene des inconvenients a peu pres aussi gros que les avantages
Je te laisse en tirer les conclusions pour debian.
Ouh la belle attaque facile… "Utiliser une version de test", mais ça vous fait pas mal parfois ? Tu es conscient que "testing" est une classification de niveau d'intégration de la distribution et que ça n'a pas le même sens qu'une beta pour un logiciel ?
Oui, j'en suis conscient. Toujours est il que testing s'appelle testing et pas stable, pour une bonne raison. Et experimental s'appelle comme ca pour une raison aussi.
Fait un apt-get update sur un des deux,t'as des chances d'avoir un systeme en carafe, et ca c'est inacceptable, desktop ou pas.
Je rappelle également que sid sert (servait ?) de base à Ubuntu…
Base qui est stabilisee avant d'etre distribuee. La question c'est pas de savoir si "oh mon dieux ubuntu est basee sur sid", mais "est il possible d'avoir des softs a peu pres recent sur debian sans devoir prendre un risque demesure pour l'integrite de ses paquets?".
Tu peux branler le mamouth tout ce que tu veux, la reponse est non. Soit t'as des vieux softs, soit t'as des ppa des bois, qui vont a l'encontre du concept de distro (avec en plus tous les problemes de secu que ca amene). Ou les backports, si t'as de la chance.
La version packagée dans testing a 2 mineures de retard et date de septembre 2014. C'est pas ce que j'appelle une "vieille" version.
Experimental est à jour.
Tu resumes efctivement tres bien debian. Faut utiliser une version de test pour avoir un soft vieux de 6 mois, et une version experimentale pour avoir un soft a jour.
Et quand la version de test deviendra stable, tu seras bloque pendant 3 ans avec un soft vieux d'un an au moment de la sortie.
C'est plus long, plus complexe au départ, mais sur du moyen/long terme tu maîtrises nettement mieux les choses.
Ca depend si faire les acquisitions c'est ton coeur de metier (j'en sais rien, peut etre, mais j'ai l'impression que c'est plutot d'etudier les donnees). Si ca l'est, oui, t'y gagnes probablement, sinon, c'est tres probablement une erreur de faire ca plutot que de payer quelqu'un dont c'est le metier de developer ce genre de technologie.
Une autre facon de dire ca est que tu finit "prisonnier" de ta propre technologie.
Pour libreoffice, on peut avoir le même type de raisonnement : plutôt que de payer des licences MS Office, on pourrait mettre cet argent pour développer libreoffice. Au début on a un logiciel moins bien, mais sur du long terme, tous les utilisateurs de libreoffice en profite.
Alors, chef, voila l'idee geniale que j'ai eu: plutot que de payer pour un produit qui marche aujourd'hui, on va utiliser un produit gratuit qui repond pas au besoin, et filer le pognon a quelqu'un controle pas, en esperant tres fort que a) il va faire ce qu'on veut et que b) il le fera suffisament vite. Et dans qq annees, on recommence pour les nouvelles features qu'office a ajoute entre temps. Elle est geniale mon idee, non?
[^] # Re: Un peu de lecture
Posté par groumly . En réponse au journal Vivent les journaux binaires !. Évalué à 3.
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.
[^] # Re: Un peu de lecture
Posté par groumly . En réponse au journal Vivent les journaux binaires !. Évalué à 5.
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.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par groumly . En réponse au journal Vivent les journaux binaires !. Évalué à 3.
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).
[^] # Re: Mais systemd le fait mal
Posté par groumly . En réponse au journal Vivent les journaux binaires !. Évalué à 4.
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.
[^] # Re: Mélange
Posté par groumly . En réponse au journal HTTP poussé vers la sortie ?. Évalué à -10.
Enculeur de mouche, t'as tres bien compris ce que je voulais dire.
[^] # Re: Mélange
Posté par groumly . En réponse au journal HTTP poussé vers la sortie ?. Évalué à -1.
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?
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.
[^] # Re: Mélange
Posté par groumly . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 0.
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.
[^] # Re: Mauvais problème
Posté par groumly . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 1.
Tu propose pas d'alternative, tu rales juste la.
Donc je repose la question, ton alternative plus fiable que https, ca serait quoi?
[^] # Re: Mauvais problème
Posté par groumly . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 2.
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.
[^] # Re: Mauvais problème
Posté par groumly . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 2.
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?
[^] # Re: Mauvais problème
Posté par groumly . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 4.
La requete montrera pas grand chose, a part une ip.
Ip qui peut etre un proxy vers wikipedia (ou autre chose).
[^] # Re: Mélange
Posté par groumly . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 4.
Le chiffrement ne sert strictement a rien si tu ne sais pas a qui appartient la cle avec laquelle tu chiffre.
[^] # Re: Mir
Posté par groumly . En réponse à la dépêche Sortie d’Ubuntu 15.04. Évalué à 2.
J'ai du mal a suivre.
Qu'est ce qui est impressionant dans la video?
Le mode fenetre? Le double ecran sur le telephone?
[^] # Re: New school
Posté par groumly . En réponse au journal Kubuntu 15.04 et Systemd : bof. Évalué à 2.
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?
[^] # Re: Les temps ne changent pas partout
Posté par groumly . En réponse au journal Les temps changent. Évalué à 4.
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.
[^] # Re: Sans UUOC
Posté par groumly . En réponse au journal le shell trick tout pourri du vendredi : .lsignore. Évalué à 8. Dernière modification le 25 avril 2015 à 06:19.
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…
[^] # Re: Et DANE simplement
Posté par groumly . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 4.
Web? T'es sur? On parlerais pas d'internet des fois?
[^] # Re: cp
Posté par groumly . En réponse au journal lns: ln -s pour les étourdis. Évalué à 5.
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.
[^] # Re: Correction
Posté par groumly . En réponse au journal Loi renseignement : OVH, Gandi et consorts seront forcés à quitter la France. Évalué à -7.
Lol.
[^] # Re: De l'openwashing
Posté par groumly . En réponse au journal Windows éventuellement en open source?. Évalué à 5.
C'est inacceptable pour quiconque travaille sur sa machine, la disponibilite de l'os doit etre de 100%.
Non, mais tu noies le poisson. Le fait est que l'erreur est humaine, et que ca arrive de deployer accidentellement une mise a jour qui pete des choses. MS l'a fait, Apple l'a fait aussi, ca reste rarissime, et ils se font gueuler dessus comme du poisson pourri quand ca arrive, parce que c'est pas cense arriver.
Ya une difference avec le mode de fonctionnement de testing/experimental, ou les patchs sont balances quasiment sans tests, et les utilisateurs sont censes les rapporter ces bugs.
Si ta testing te pete a la gueule, on te repond "euh, ben oauis. C'est une testing, ca arrive, on va voir si on peut corriger ca". Si t'insiste pour que ca soit corriger "la, main'nant toussuite", on va t'envoyer chier, a raison, on va te pointer le repo stable.
Si ta stable te pete a la gueule, c'est une faute grave de la part de l'equipe responsable, et ils bossent non stop pour corriger ca.
Si tu comprends pas la difference entre les deux, je sais pas quoi te dire.
En quoi peut on reprocher a debian d'avoir fait ce choix? Peut etre parce que c'est eux qui ont fait ce choix? Que tu soit libre de pas utiliser debian (encore heureux!) ne change pas grand chose aux decisions qu'a fait debian.
[^] # Re: De l'openwashing
Posté par groumly . En réponse au journal Windows éventuellement en open source?. Évalué à 5.
Ben ca peut vouloir dire 2 chose:
- soit une distro qui dure plus de 6 mois est une mauvaise idee
- soit le concept de repo central est pas aussi genial que certain le laissent entendre, et ramene des inconvenients a peu pres aussi gros que les avantages
Je te laisse en tirer les conclusions pour debian.
[^] # Re: De l'openwashing
Posté par groumly . En réponse au journal Windows éventuellement en open source?. Évalué à 0.
Oui, j'en suis conscient. Toujours est il que testing s'appelle testing et pas stable, pour une bonne raison. Et experimental s'appelle comme ca pour une raison aussi.
Fait un apt-get update sur un des deux,t'as des chances d'avoir un systeme en carafe, et ca c'est inacceptable, desktop ou pas.
Base qui est stabilisee avant d'etre distribuee. La question c'est pas de savoir si "oh mon dieux ubuntu est basee sur sid", mais "est il possible d'avoir des softs a peu pres recent sur debian sans devoir prendre un risque demesure pour l'integrite de ses paquets?".
Tu peux branler le mamouth tout ce que tu veux, la reponse est non. Soit t'as des vieux softs, soit t'as des ppa des bois, qui vont a l'encontre du concept de distro (avec en plus tous les problemes de secu que ca amene). Ou les backports, si t'as de la chance.
[^] # Re: De l'openwashing
Posté par groumly . En réponse au journal Windows éventuellement en open source?. Évalué à 1.
Tu resumes efctivement tres bien debian. Faut utiliser une version de test pour avoir un soft vieux de 6 mois, et une version experimentale pour avoir un soft a jour.
Et quand la version de test deviendra stable, tu seras bloque pendant 3 ans avec un soft vieux d'un an au moment de la sortie.
[^] # Re: De l'openwashing
Posté par groumly . En réponse au journal Windows éventuellement en open source?. Évalué à -1.
Ca depend si faire les acquisitions c'est ton coeur de metier (j'en sais rien, peut etre, mais j'ai l'impression que c'est plutot d'etudier les donnees). Si ca l'est, oui, t'y gagnes probablement, sinon, c'est tres probablement une erreur de faire ca plutot que de payer quelqu'un dont c'est le metier de developer ce genre de technologie.
Une autre facon de dire ca est que tu finit "prisonnier" de ta propre technologie.
[^] # Re: mauvaise relation de cause a effet
Posté par groumly . En réponse au journal techos bradés. Évalué à 0.
Super, t'as trouve un site subjectif, rempli de pub et qui cite pas ses sources.
Clairement, ils doivent avoir raison!