Le projet Debian est doté d'un comité technique qui est chargé de prendre des décisions techniques, notamment dans les cas de conflits. Il y a quelques mois, le comité a été saisi pour décider du système d'initialisation par défaut pour la prochaine version de Debian, Jessie. Les candidats étaient : le vénérable init System V (utilisé dans la version actuelle de Debian, Wheezy), Upstart de Canonical, systemd de Lennart Poettering (RedHat) et OpenRC de Gentoo).
Cette question a suscité un intense débat, qui vient d'être tranché hier soir :
We exercise our power to decide in cases of overlapping jurisdiction
(6.1.2) by asserting that the default init system for Linux
architectures in jessie should be systemd.Should the project pass a General Resolution before the release of
"jessie" asserting a "position statement about issues of the day" on
init systems, that position replaces the outcome of this vote and is
adopted by the Technical Committee as its own decision.
Plusieurs points sont à noter :
- Il s'agit du système d'initialisation par défaut pour les architecture basées sur le noyau Linux. En particulier, les architectures — largement minoritaires — basées sur GNU Hurd ou sur le noyau de FreeBSD ne sont pas concernées par cette décision. Par ailleurs, comme aujourd'hui, où le système d'initialisation par défaut est celui de System V mais où systemd et Upstart sont tout de même disponibles et utilisables, ce choix pour la prochaine version de Debian laisse la possibilité de proposer des systèmes d'initialisation alternatifs.
- Cette décision peut laisser la place à une éventuelle résolution générale, c'est à dire un vote général des membres du projet Debian si elle est convoquée par un nombre suffisant de membres.
- Cette décision ne répond pas à toutes les questions, en particulier celle des dépendances des paquets Debian, comme le fait remarquer Eric Schubert.
# Mon avis personnel
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Mon avis personnel : je n'aime pas systemd, qui bien qu'étant basé sur de très bonnes idées est à mon avis développé et promu de façon désagréable, avec ce qui m'apparaît comme une volonté hégémonique sournoise. Mais comme je le mentionne, il ne s'agit là que du choix d'init par défaut, et j'espère donc pouvoir continuer à utiliser l'init et les services SysV.
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à 3.
Ca me démange de faire un commentaire, mais je me retiendrai … Juste une question : qu'en est-il de l'idée de mettre les logs sous forme binaire? Ca a été fait ?
[^] # Re: Mon avis personnel
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Avec journald, ça doit être le cas oui, mais est-ce que ça affecte tous les logs, je ne sais.
[^] # Re: Mon avis personnel
Posté par flagos . Évalué à 4.
Il me semble qu'il y a une option avec journald pour retrouver des log en texte.
[^] # Re: Mon avis personnel
Posté par cosmocat . Évalué à 2.
Petit complément : Si j'ai bien compris, le format de stockage de journald est toujours binaire mais il est possible de faire un export en texte…
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à 8.
Et je fais comment si par exemple je démarre en mode minimal en raison d'un plantage quelconque, et que le problème affecte également l'outil d'export des logs ? Je pense par exemple à un fs corrompu ou à une mauvaise version de bibliothèque.
Pour être franc, c'est probablement la raison principale qui me fait détester à ce point systemd, avec le fait que systemd veut s'occuper de choses qui ne le regardent pas.
Il y a d'autres choses que je n'aime pas, mais sans ce point ça passerai peut-être mieux
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 1.
Un truc qui t'empêcherais carrément de brancher le disque sur une autre machine ou de booter sur une live ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à 4.
Juste pour regarder des logs ? Je parle pas du PC chez soi, mais d'un serveur, qui potentiellement ne serait pas accessible car posé en salle blanche. Même si la réparation ne peut pas se faire de suite, il est indispensable de pouvoir diagnostiquer au plus vite un problème. Ca permet aussi de ne pas avoir à faire des longues et pénibles dé&marches pour accéder en salle pour rien.
[^] # Re: Mon avis personnel
Posté par gnumdk (site web personnel) . Évalué à 8.
Va falloir que tu m'expliques comment tu analyses un serveur qui a un fs corrompu ou une mauvaise version de lib (tu fais des ./configure --prefix=/usr sur un serveur toi?) ???
Parce que si c'est le cas, y'a de grande chance que tu ne sois pas capable de faire mieux avec les commandes de bases qu'avec journalctl…
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à 3.
Ben vu le nombre de libs utilisées par l'outil de systemd par rapport à cat/grep/etc … j'ai plus de chances de voir ce qui se passe rapidement. Je ne pourrai peut-être pas réparer, mais je saurai ce qui se passe.
[^] # Re: Mon avis personnel
Posté par Renault (site web personnel) . Évalué à 5.
Ce n'est pas 3 petites bibliothèques en plus de cette taille qui vont ralentir considérablement journald.
Arrête ton FUD un peu, les bibliothèques en plus ne sont pas forcément utilisées en permanence déjà (peut être pour certains cas précis) et ne sont pas lourds. Journald n'est pas un bloatware, tu aurais pu le dire si cela dépendait de Qt, GTK+, l'API Java, autre bibliothèque lourde et sans rapport direct avec l'activité.
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 6.
Tu as déjà entendu parler de busybox ?
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 3.
Tu fais quoi aujourd'hui si le FS est mort ? Si vraiment c'est une partition spécifique tu peux faire tenter avec des outils de récup' style photorec ça ne change rien entre journald et autre. Si ton problème c'est juste que ton serveur est mort (problème de lib), tu peux toujours récupérer le fichier et l'analyser en local (comme tu le fais déjà :) ).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à 1.
Je ne parle pâs de fs complêtement mort : je parle plutôt d'un secteur disque qui lacherait là ou les libs en question se trouvent. Mais vu que les messages peuvent être forwardés vers la syslog, la question ne se pose plus …
[^] # Re: Mon avis personnel
Posté par Renault (site web personnel) . Évalué à 7. Dernière modification le 12 février 2014 à 15:28.
Et si ça tombe sur le binaire de cat ? Et si la météorite tombe sur le serveur ? Et si un incendie se déclare dans la salle blanche ?
Des cas hypothétiques rarissimes on peut en trouver plein pour dire que tel outil ne s'en sort pas, la question est de savoir si dans la vraie vie ça répond au besoin… Car en partant du principe que ton disque dur est endommagé, c'est le fichier de logs ou tes binaires habituels qui pourraient être touchés aussi et tu serais bloqué également.
[^] # Re: Mon avis personnel
Posté par needs . Évalué à 6.
Fort heureusement, il n'y a pas qu'un seul outil qui permet de lire un fichier texte, alors qu'il y en a qu'un seul pour lire les logs de journald. Et c'est dans les situations improbable que l'on prend conscience de la qualité d'une architecture logicielle. Pour faire plus simple, le plus compliqué n'est pas de faire un programme qui fonctionne dans 99% des cas, mais un programme qui fonctionne dans 99.99% des cas.
Des bons outils auront moins tendance à te lâcher dans les situations difficiles. Faire le choix d'un format binaire que peu d'outils savent manipuler, surtout pour une chose aussi cruciale que les logs, ça témoigne d'un manque d'expérience et je suis sûr que certains en feront les frais.
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 7.
Ou pas. D'une part, à l'usage on se rend compte que journald permet de chercher les infos pertinentes bien plus rapidement qu'avec du bidouillage avec grep & co.
En plus, les raisons pour le choix du format binaire ont été expliqués de nombreuses fois.
Et enfin pour les gens qui ne sont toujours pas content, la copie vers syslog s'active en une ligne :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 10.
Si tu souhaites avoir une bonne gestion des logs et permettre des analyses éventuellement poussées, il ne faut de toute manière pas les garder sur la machine (qui peut de toute manière partir en vrille, tant pour journalctl que grep ou cat).
Part sur une centralisation des logs avec des outils comme logstash + elastic search + kibana3, graylog2, les 2 ensembles…, ou un très onéreux splunk si le ROI le permet.
Cela offre plein d'avantages:
- logs harmonisés (formats de date, encodage…) et qualifiés (date, processus, multiligne [trace java]…)
- Recherche rapide dans les logs grâce à un moteur de cherche, possibilité de créer des graphiques
- De comprendre des anomalies liés à une combinaison de facteurs, éventuellement répartie sur plusieurs machines
- D'analyser même si la machine fait du kernel panic
- D'analyser en temps réel, déclencher des alertes
- Donner la capacité d'analyser des problemes aux développeurs, sans ouvrir d'accès aux machines de prod (et brouillage des infos sensibles)
- Utiliser ou déclencher des événements entre machine via de la messagerie comme AMQP, ce qui permet par d'exemple d'ajouter ou retirer des noeuds à un cluster en fonction de temps de réponses)
Lorsqu'on qu'on voit en plus comment cela peut être simple et puissant de mettre en place un logstash, je ne comprends même pas que l'on puisse encore vouloir s'emmerder avec rotations, cat et grep, qui sont des silex à coté. Je ne dis pas que cela ne peut pas aider de temps à autre pour des trucs rapide et sans importance, mais pour le reste, il y a bien mieux aujourd'hui.
Si le sujet t'intéresse, prends 30min et regarde cela http://www.youtube.com/watch?v=RuUFnog29M4#t=353 et cette dépêche: https://linuxfr.org/news/gestion-des-logs-avec-logstash-elasticsearch-kibana
Je pense que dans quelques temps, lorsque les versions stable Redhat/Centos utiliseront en standard journald (qui génére des logs de qualité) envoyé dans un outil comme logstash+elastic search+kibana3 + graylog2, on aura une arme libre assez incroyable au niveau des logs. Allo quoi…
[^] # Re: Mon avis personnel
Posté par YBoy360 (site web personnel) . Évalué à 0.
Je suis énervé, il est tôt et je tappe depuis mon téléphone portable. Bref, je pige pas qu'il y en ait encore pour remettre en cause la pertinence de journalctl.
Je trouve que les géniteurs de systemd ont vraiment du mérite à supporter des débats d'un tel niveau. Je trouvais leurs méthodes un peu directe, mais franchement, arriver à mélanger autant de concepts, pour justifier n'importe quoi, c'est faire preuve soit de malice, soit d'inexpérience.
Je ne vais pas me contenter de donner un avis personnel, mais sans être du niveau d'un Shannon, on sait tous, sans exception, que plus on transforme une donnée (par exemple une date en long (Long long) vers char[]) plus on perd de l'information de base, plus on perd du temps pour faire la conversion, plus on perd du temps a faire la conversion inverse pour pouvoir agir efficacement sur la donnée de base (par exemple si je veux juste les lignes d'un intervalle de temps), plus on est obligé de specifier comment convertir l'info, on doit mettre en plus tout le monde d'accord… je pourrais continuer, en gardant le format binaire de base, TOUT cela est inutile.
De plus, journalctl apporte bien plus que seulement le respect des formats binaire de base.
Je trouve logstash très intéressant si tu utilises syslog old school et si tu as 30 serveurs pour stocker tes log, je ne reproche rien au message du dessus.
[^] # Re: Mon avis personnel
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
Déja je corrige mon message, je voulais dire "Redhat/Centos et Debian".
Ensuite, je crois que tu te plantes sur "logstash très intéressant si tu utilises syslog old school et si tu as 30 serveurs pour stocker tes log". Mais je peux comprendre que l’énervement des fudeurs et autre conservateurs n'aide pas…
Sur le coté syslog old school: logstash permet d'agreger et d'hamoniser les logs venant de plusieurs sources (dont syslog certes) mais permet donc de s'affranchir de ses limites. Avec des appli java, utiliser syslog signifie tronquer les messages par exemple. Avec un parc hétérogène (windows, linux variés, éléments réseaux….), c'est une bonne solution pour avoir quelque chose d'exploitable.
Et sur le coté "30 serveurs pour stocker tes log", il faut juste ne pas être trop archiviste ou collectionneur, mais suivre le cycle de vie:
- Enregistrer
- Transmettre
- Analyser
- Stocker
- Détruire (a ne pas oublier)
Elastic search est clusterisable certes (contrairement à find/grep d'ailleur), mais on s'en sort généralement très bien avec une seule machine si on n'a pas une ame de syllogomane ;)
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 1. Dernière modification le 13 février 2014 à 10:37.
Tu t’énerves pour rien, ce n’est pas très bon pour la santé. Personne ne remet en cause la pertinence de journald, seulement le choix d’un format binaire pour l’implémentation.
[^] # Re: Mon avis personnel
Posté par Alex . Évalué à 4.
Je comprends pas trop le troll
la format binaire est obligatoire, mais vu qu'apparemment il peut être utilisé conjointement à un format texte, on a le meilleur des 2 mondes
[^] # Re: Mon avis personnel
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Pour combien de temps ? Je me méfie des promesses de Lennart Poettering, du genre « non non, ne vous inquiétez pas, udev est maintenu dans le dépôt de systemd mais il n'en dépendra jamais ».
[^] # Re: Mon avis personnel
Posté par Maclag . Évalué à 10.
Moi aussi, je pense qu'elle disparaîtra. Faut juste laisser le temps aux gens de s'habituer à l'idée d'un format binaire, rôder le système, passer la peur initiale, et attendre que les scripts maison deviennent obsolètes par eux-mêmes.
Un jour, Poettering (et encore, je dis Poettering, mais je ne sais même pas qui maintient ou maintiendra cette partie du code!) dira qu'il ne souhaite plus maintenir le convertisseur, et là, deux possibilités:
-Quelqu'un dans la marée des "oh non! surtout pas!!" prendra la relève pour de vrai et pas seulement en râlant
-Personne ne prend la relève, et on aura des kilomètres de Troll sur Poettering qui impose une fois de plus ses choix aux autres.
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 10.
on aura pleins de gens qui vont se lever crier « Oh ! Non surtout pas ! », mais pas un pour mettre les mains dans le cambouis.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par Alex . Évalué à 1.
Pourquoi disparaitre ? les 2 ont leur utilité
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 5.
Donc en gros quoi qu'il dise quoi qu'il fasse ta va gueuler (tu as signé la pétition contre lui ?). Au final quitte Debian et passe soit à Gentoo, soit à Arch soit à une BSD, ça t'évitera un ulcère.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par Astaoth . Évalué à 2.
Arch utilise systemd, bien tenté.
Emacs le fait depuis 30 ans.
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 3.
J'ai écris Arch en pensant Slack.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par gouttegd (site web personnel) . Évalué à 10.
Pas la peine, Slackware passera à systemd tôt ou tard.
Aux dernières nouvelles, Patrick Volkerding n’a encore pris aucune décision, mais il ne reste pas (ne peut pas rester) indifférent à ce qui se passe dans le reste du monde GNU/Linux :
Compte tenu du champ couvert par systemd (qui ne se limite pas à Udev, contrairement à ce que Pat semble croire à l’époque), il me paraît totalement irréaliste d’imaginer (espérer ?) que Patrick Volkerding pourra maintenir à lui tout seul des remplaçants à toutes les API de systemd. Dès lors que des programmes se mettront à dépendre de ces API, il est plus vraisemblable que la conclusion des développeurs de systemd s’imposera à lui :
À mon avis, il n’y a pas grand’chose à attendre des distributions GNU/Linux pour ceux qui ne veulent définitivement pas de systemd (mais qui ne sont pas disposés à maintenir une alternative).
Je pense que systemd a gagné. Je ne suis pas sûr que ça me plaise, mais c’est un constat.
J’espère seulement qu’on ne réalisera pas dans cinq ans que c’était une mauvaise idée. Ou pire, qu’on ne verra pas arriver dans cinq ans un Lennart Poettering bis qui convaincra tout le monde qu’il faut remplacer systemd par son nouveau truc révolutionnaire, renvoyant systemd rejoindre HAL, ConsoleKit et quelques autres dans le cimetière des composants à la vie éphémère, que les distributions ont à peine le temps d’intégrer avant qu’ils ne soient déclarés obsolètes.
¹ Interview with Patrick Volkerding of Slackware
[^] # Re: Mon avis personnel
Posté par zul (site web personnel) . Évalué à 2.
On peut espèrer qu'il ne sera pas tout seul. C'est quand même l'aspect problématique majeure pour les systèmes libres non-linux (ou les cas limites des systèmes linux où on voudrait utiliser linux sans devoir utiliser l'artillerie lourde d'init systemd (genre l'embarqué)).
[^] # Re: Mon avis personnel
Posté par cedric . Évalué à 5.
Va falloir definir de quel type d'embarque dont tu parles. Parce que il y a une raison pour que OpenEmbedded utilise systemd depuis quelques temps ! Et dans le cas de machin trop petit pour systemd, tu vas franchement pas etre loin de devoir coder ton init tout seul…
[^] # Re: Mon avis personnel
Posté par zul (site web personnel) . Évalué à 2.
Je ne sais pas pour OpenEmbedded Raw, mais pour yocto, le défault, ça reste sysvinit (standard). Tu peux facilement remplacer l'implémentation standard par l'implémentation de busybox. Et optionellement, tu peux choisir d'utiliser systemd comme système d'init (qui lui n'a pas d'implémentation alternative).
[^] # Re: Mon avis personnel
Posté par gouttegd (site web personnel) . Évalué à 7.
Je n’ai encore vu personne sérieusement motivé pour lever le petit doigt.¹ Tu peux toujours espérer que quelqu’un va le faire, mais tu devrais surtout espérer que tous les opposants à systemd ne vont pas faire la même chose que toi, sinon le Sauveur va se faire attendre longtemps…
Rien que garder PAM hors de Slackware n’a pas toujours été facile, et je ne me souviens pas avoir vu foule de contributeurs proposer leur aide à Patrick Volkerding pour ça (pourtant PAM a eu sa dose de détracteurs).
L’opinion des développeurs de systemd est claire dès le début : les autres systèmes, OSEF. C’est effectivement un des aspects qui me chagrine le plus. Il fut un temps où l’ambition de Linux n’était pas seulement de percer pour lui-même, mais d’ouvrir la voie pour d’autres systèmes libres. C’est fini : maintenant, c’est « on bosse pour nous, les autres n’ont qu’à se débrouiller. »
¹ D’une certaine façon, c’est logique : la plupart des opposants à systemd sont satisfaits de ce qu’ils ont actuellement (c’est mon cas par exemple), donc ils sont convaincus qu’il n’y a rien à faire (“if it ain’t broke, don’t fix it”), donc ils ne font rien. Si en face il y a des insatisfaits qui, eux, sont prêt à faire quelque chose, il n’y a rien d’étonnant à ce que ce soit ces derniers qui aient le dernier mot. Dans le logiciel libre, ceux qui codent sont ceux qui emportent la décision.
[^] # Re: Mon avis personnel
Posté par Renault (site web personnel) . Évalué à 7.
Soyons clair, le système d'init (enfin, ses scripts) n'est pas commun entre les distributions Linux eux mêmes alors la compatibilité avec d'autres UNIX c'est encore pire. Je ne vois pas l'intérêt de garder un semblant de lieu commun alors que dans les faits ça fonctionne déjà différemment.
De plus, je pense que certaines couches basses du système doivent être en mesure d'exploiter l'API du noyau quand le gain est jugé appréciable. SI on considère que la seule API valable c'est POSIX, alors quel intérêt à ajouter des trucs cools dans le noyau si c'est pour ne pas les exploiter en raison de la sacro sainte compatibilité ?
La compatibilité c'est important, mais je pense qu'elle ne doit pas être une règle absolue et que cela dépend du gain fonctionnel à ne pas l'être. Un système d'init est de fait trop spécifique au système pour que la question de la portabilité soit réellement pertinente.
C'est un peu le paradoxe de l'univers UNIX. Il y a plein de systèmes différents ce qui apporte de la diversité. Mais on souhaite que tout soit compatible avec tous les autres. Quel intérêt d'avoir des systèmes différents ? Est-ce qu'une API de noyau en commun serait vraiment intéressant ? Les systèmes UNIX ont su faire des scripts de démarrage incompatibles entre eux depuis 40 ans, systemd aura au moins fusionné la situation pour Linux et pour le reste la situation ne changera pas.
[^] # Re: Mon avis personnel
Posté par zul (site web personnel) . Évalué à 3.
Je ne parlais pas du système d'init en tant que telle, mais systemd comme dépendance dure dans des logiciels 'tiers'. Par exemple, gdm dépend maintenant de logind pour un certain nombre de choses. Bref, pour l'instant, quelques fonctionnalités de moins dans gnome pour les BSDistes. Quand des applications vont se mettre à utiliser l'API journal pour logger, de facto, ça ne marchera plus que sur les systèmes avec systemd (i.e. plus Solaris, plus *BSD, …). Bref, si il n'y a pas d'implémentation alternative, de plus en plus d'applications seront linux-only.
[^] # Re: Mon avis personnel
Posté par Renault (site web personnel) . Évalué à 10.
Tu te trompes d'ennemi alors. C'est à GNOME de rendre son code assez modulaire pour s'adapter aux couches plus basses et être portable. systemd n'y est pour rien si GNOME ne se conforme qu'à son API pour certains trucs. Cela signifie deux choses :
Bref, systemd n'est pas ton ennemi, le problème sont les couches hautes qui veulent uniquement systemd pour fournir leur service.
Vas-tu accuser Linux d'avoir inventer KMS ou les cgroups ce qui crée une rupture ? C'est la faute à qui si les couches hautes les utilise sans alternative ? Linux qui propose un service ou le code des couches hautes qui n'a pas fait l'effort de portabilité ?
[^] # Re: Mon avis personnel
Posté par Albert_ . Évalué à -2.
Euh oui mais bon systemd c'est 99% RedHat et Gnome aussi donc qui doit on accuser la? On est vraiment dans un cas de figure ou la main droite ne sait pas ce que fait la main gauche ou la dependance a systemd est totalement volontaire?
[^] # Re: Mon avis personnel
Posté par Maclag . Évalué à 5.
Tous les dévs du monde qui ne sont pas d'accord avec les choix techniques, sont compétents sur la question, et ne se sortent pas les doigts du ***?
L'ensemble des clients de RedHat qui refuse catégoriquement ses choix et ferme sa gueule?
Ou alors il n'y a personne à accuser parce qu'il n'y a pas de crime?
Ça m'amuse qu'on dise que RedHat est trop gros et a trop d'influence. Il suffirait aux autres de ne pas utiliser les solutions produites par RedHat.
Ah ben non, visiblement les dévs des autres distros sont nombreux à trouver que ce sont de bonnes choses.
On leur dit quoi à eux?
Coupables?
Syndrome de Stockholm?
"Nan mais z'êtes trop cons, 'vais vous dire moi comment qui faut faire vot'boulot!"
[^] # Re: Mon avis personnel
Posté par Zenitram (site web personnel) . Évalué à 1.
La, tu te trompes d'accusé.
La faute en revient à ces mauvais logiciels qui décident unilatéralement de dépendre de systemd. Pourquoi font-il ça? A eux de savoir gérer plusieurs méthodes (et c'est normal, c'est la vie, comme Gnome décide de ne pas être compatible avec Windows et j'en passe).
Perso, je ne comprend pas ce "hard link" de Gnome, ça n'a rien à faire (au pire, la fonctionnalité est manquant si systemd/logind n'est pas disponible sur la machine, en attendant que quelqu'un code le "pont" entre gnome et une autre lib).
systemd est pas mal le bouc emissaire… Tout la faute de systemd, même si il n'a rien fait sur ce sujet, de toute façon les anti-systemd ne vont pas réfléchir et vont se dire "encore le méchant" sans chercher à accuser les vrais responsables :(.
[^] # Re: Mon avis personnel
Posté par zul (site web personnel) . Évalué à 1.
Faut arrêter la parano les gars. Je disais juste qu'on pouvait espérer voir des implémentations alternatives à certains API de systemd, parce que ça risquait de se révéler nécessaires étant donné l'utilisation qui en était faite. Dans ce cas, on peut considérer deux alternatives:
- patcher tous les logiciels qui utilisent ces API et fournir un autre moyen de faire la "même chose", ou au moins un mode dégradé
- tendre vers un "standardisation" de l'API (ce qui me parait l'approche efficace et vertueuse), i.e. une API avec plusieurs implémentations (ou avoir une implémentation portable).
Après, on peut se poser des questions sur la stratégie systemd ? Pourquoi journald et l'API associé sont dans systemd par exemple ? Pourquoi ce n'est pas simplement une bibliothèque et un daemon indépendant qui pourrait être utilisé partout ? Cette politique de centralisation + le non-acceptation de patch pour des systèmes tiers rend l'utilisation de ces API plus difficile qu'elle ne devrait l'être (il me semble).
Concernant KMS, c'est une bonne chose. Le fait que les drivers Xorg nécessitent tous KMS est certainement une chose intéressante, mais elle rend la situation très difficile pour les systèmes non-Linux (même si tous les BSD vont finir par avoir une implémentation de KMS / TTM / GEM). Je ne parle même pas de Wayland, qui va encore être une autre paire de manche :). Bref, la situation n'est pas forcément facile pour les *BSD.
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 3.
Référence nécessaire.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par gouttegd (site web personnel) . Évalué à 5.
« Il était une fois Linux », par Linus B. Torvalds, paru chez Osman Eyrolles Multimédia. Patientez jusqu’à ce soir que je rentre chez moi, je vous retrouverai la page exacte.
[^] # Re: Mon avis personnel
Posté par gouttegd (site web personnel) . Évalué à 8.
Alors, c’est page 278 dans l’édition française de 2001. Linus vient d’évoquer la possibilité dans l‘avenir que des développeurs créent de nouveaux systèmes d’exploitation (« Fredix » ou « Diannix ») pour remplacer Linux qui d’ici là commencera à accuser le poids des ans — une possibilité qu’il juge probable et même désirable, parce que « c’est ainsi que cela doit être. »
Voilà d’où je tire l’idée que le premier développeur de Linux ne voulait pas seulement créer un système d’exploitation libre, mais aussi rendre la tâche plus faciles à de futures développeurs de nouveaux systèmes d’exploitation — ouvrir la voie à ses propres successeurs. Un hacker déteste avoir à résoudre à nouveau un problème déjà résolu par d’autres et souhaite que ses efforts servent à d’autres hackers, nous dit Eric Raymond. Faire percer Linux a été difficile, et en bon hacker, Linus souhaitait que d’autres systèmes puissent s’engouffrer dans la brèche à sa suite au lieu de devoir percer leur propre trou tout seul.
C’est cette ambition qui, à mon sens, a disparu aujourd’hui. GNU/Linux a réussi, et on s’en contente. On se satisfait de pilotes propriétaires qui ne fonctionnent qu’avec Linux, sans plus déplorer l’absence de pilotes libres (ou mieux, de spécifications) dont pourraient profiter d’autres systèmes. On s’offusquait avant que tel logiciel ne soit disponible que pour Windows et Mac OS, aujourd’hui on est ravi d’avoir seulement ajouté Linux à la liste. On regarde de haut les autres systèmes libres (comme les BSD qui « ne sont plus pertinents aujourd’hui », dixit Poettering), alors qu’on souffrait hier encore d’être regardé de haut par les systèmes propriétaires…
Je n’imagine pas un successeur à Linux émerger dans de telles conditions et être accueilli favorablement.
¹ Pour ceux qui trouveraient que c’est là une définition beaucoup trop succinte et réductrice de la philosophie Open Source, Torvalds venait de consacrer tout le chapitre précédent à expliquer et défendre ladite philosophie, donc il n’y avait donc nul besoin pour lui de développer davantage dans ce paragraphe.
² C’est moi qui souligne.
[^] # Re: Mon avis personnel
Posté par claudex . Évalué à 6.
Le problème, c'est que Linux évolue bien plus vite que les autres. Que doit-on faire en attendant les autres ? Doit-on arrêter de développer la virtualisation en attenant qu'OpenBSD ait quelque chose d'utilisable ? Doit-on arrêter de développer l'OpenCL et l'accélération 3D en attendant qu'Hurd sache ce que ça veut dire ? Doit-on ne pas utiliser les cgroups en attendant que NetBSD développe un truc similaire ?
Vu comme les gens râlent quand on remplace leur système de log par un truc compatible avec l'existant, je n'ose pas imaginer ce qui se passerait si on leur changeait le noyau.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mon avis personnel
Posté par gnx . Évalué à 2.
Une grosse différence est qu'on ne leur changerait pas le noyau, mais que certains opteraient pour un nouveau noyau ou OS. Comme par exemple quand certains d'entre nous sont passés de DOS/Windows à Linux, ce n'est pas le noyau Linux qui est rentré dans DOS ou Windows ; DOS et Windows sont restés tels quels et ont évolué de leur côté.
Ou comme dans le cas actuel si la joyeuse compagnie avait créé Poetterix (que ce soit à partir de Linux, avec des bouts de Linux ou à partir de zéro) sans chercher à influer directement sur Linux.
[^] # Re: Mon avis personnel
Posté par claudex . Évalué à 4.
Pour systemd, ils n'ont pas influencer Linux, ils ont utilisé ce qu'il y avait dans Linux pour avoir un système qui tire pleinement partie des possibilités offertes par le noyau.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mon avis personnel
Posté par gouttegd (site web personnel) . Évalué à 8.
Euh, si. Les développeurs du noyau et ceux des programmes en espace utilisateur qui ont directement à faire avec le noyau se parlent, quand même. Ce ne sont pas juste les premiers qui font quelque chose puis les seconds qui suivent. Il y a influence dans les deux sens.
Dans le cas de systemd, il y a notamment eu de nombreux échanges avec les développeurs noyau en charge des cgroups, qui vont conduire prochainement :
– d’une part, à une certaine simplification de l’API des cgroups (l’API actuelle est jugée a posteriori inutilement complexe — notamment, la possibilité d’avoir une hiérarchie indépendante par contrôleur laissera la place à une hiérarchie unique pour tous les contrôleurs) ;
– d’autre part, à ce que systemd masque complètement les cgroups pour ne présenter au reste de l’espace utilisateur qu’une abstraction (à l’avenir, aucun programme à part systemd n’utilisera directement les cgroups, ils devront passer par systemd).
C’est là une évolution notable de tout le dispositif des cgroups, directement influencé par systemd, en tant qu’utilisateur intensif de ceux-ci.
(Avant qu’on me dise que je suis un vieux con réfractaire au changement — ce qui est faux, je ne suis pas vieux —, je précise que je ne vois pas forcément cette évolution d’un mauvais œil.)
[^] # Re: Mon avis personnel
Posté par Guillaume Denry (site web personnel) . Évalué à 7.
Et bien pour l'instant le pari de Linus est gagné, de nouveaux territoires techniques sont défrichés, et le noyau et systemd sont totalement libres.
Alors, veux-tu dire que systemd aurait dû ignorer les avancées techniques du noyau Linux pour "respecter" les autres systèmes afin qu'eux aussi puissent profiter de systemd ?
Je veux dire, c'est beau la théorie, mais dans la vraie vie, le nombre de développeurs dans le libre est limité, si des gens sont motivés pour construire un système plus performant et mieux architecturé autour des avancés du noyau linux, mais qu'à côté personne ne l'est assez pour faire évoluer les autres systèmes vers quelque chose du même acabit, qui faut-il blâmer ?
Au final, il ne faut pas oublier qu'on a quelque chose de totalement libre, documenté, adaptable, c'est ça la grande rupture avec Windows et MacOS.
Je pense que tous ceux qui luttent pour construire des pilotes libres apprécieront :)
(et puis j'ai un peu de mal à apprécier le rapport avec le sujet ici)
Inutile d'anticiper à ce point l'avenir, le nombre de logiciels libres uniquement disponibles pour linux et pas les autres systèmes de type unix n'est pas si élevé…
J'irais même plus loin, et si l'idéal n'était pas une prolifération de systèmes d'exploitation libre (de la taille de linux et répandu à grande échelle de manière industrielle hein, je mets à part les systèmes d'exploitation expérimentaux ou de niche) mais une unification autour de quelques grands systèmes afin de concentrer les forces pour continuer à défricher de nouveaux territoires ?
[^] # Re: Mon avis personnel
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 15 février 2014 à 11:53.
Un example serait de vouloir standardiser les fichiers de config, que tous les OS aient un standard commun pour comment dépend chaque programme l'un de l'autre. L'implémentation (spécifique à Linux), on s'en fout complet, c'est normal, que le meilleur gagne.
Implémentation != standardisation des entrées (et sorties).
Mélanger les deux est ne pas comprendre le problème, et faire comme les OS qu'on critique.
[^] # Re: Mon avis personnel
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
L'abstraction, c'est souhaitable lorsque les systèmes offrent des similarités de fonctionnement, mais lorsqu'ils s'éloignent trop les uns des autres, ça devient contre-productif et comme je le disais, les gens souhaitent bosser sur ce qui leur plaît et leur quantité est limitée, donc…
[^] # Re: Mon avis personnel
Posté par Zenitram (site web personnel) . Évalué à 3.
Tant que tu acceptes cet argument quand Linux n'est pas supporté par tel site, tel logiciel… ;-)
[^] # Re: Mon avis personnel
Posté par Zenitram (site web personnel) . Évalué à -9.
Rien de nouveau chez l'être humain, amateur de Linux ou pas : la seule chose qui compte est son poulain, le reste ("être compatible", les standards…) n'est qu'une couverture le temps de réussir à écraser l'autre, de trouver sa place.
mais à la différence des utilisateurs Windows ou Mac, les Linuxiens sont persuadés d'être "meilleurs" (alors qu'ils sont exactement pareils, ils n'ont rien à faire des autres). C'est assez amusant à regarder cette notion de supériorité.
[^] # Re: Mon avis personnel
Posté par Albert_ . Évalué à 9.
mais à la différence des utilisateurs Windows ou Mac, les Linuxiens sont persuadés d'être "meilleurs"
T'en as vraiment pas marre d'insulter les utilisateurs de linux a longueur de journee? Personne ne t'oblige a utiliser ce systeme (au contraire il est pas installe par defaut sur un PC) et personne ne t'oblige a venir sur ce site.
[^] # Re: Mon avis personnel
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Il me semble que cette affirmation tient un petit peu du fantasme, la communauté du libre est très diverse, il n'y a pas d'"ambition de Linux", certains sont très attachés à l'ouverture vers les autres systèmes, certains non, ils ont juste en commun de vouloir écrire des logiciels libres.
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à 2.
Un cas simple qui est bien plus couirant que tu ne le penses : mise à jour qui foire (coupure réseau par exemple) provoquant une incohérences au niveau des libs. Ca arrive, ça m'est déjà arrivé de récupérer un serveur dans cet état. Tu fais comment si tu n'accèdes plus aux logs ?
Un format binaire, ça peut servir pour plein de choses, notamment pour des outils d'analyse. Par contre quand tu dois dépanner, c'est pas génial. Que systemd stocke des logs en format binaire, pourquoi pas, mais il faut qu'il garde les logs en mode texte également.
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 9.
Sur les distrib' que j'ai essayé les mises à jour n'ont pas besoin du réseau. Tout est téléchargé puis on met à jour.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à 2.
La coupure réseau n'est effectivement pas le bon exemple, celà n'empêche pas qu'il y a d'autres raisons qui peuvent interrompre une mise à jour (dont le ctrl+c sauvage).
[^] # Re: Mon avis personnel
Posté par pasBill pasGates . Évalué à 1.
Ca effectivement.
Ca serait bien aussi de rajouter a Linux un systeme complet de transaction comme Windows, qui permet de modifier plusieurs fichiers, modifier des entrees de config, et faire un rollback en cas de probleme, ca eviterait des problemes comme celui-ci
Je re -->[]
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 5.
Un truc genre on fait un snapshot du système de fichier, puis on fait la mise à jour et si on voit qu'il y a un problème on repasse sur le snapshot ? C'est dans les tuyaux depuis quelques temps (je crois que le principal problème c'est btrfs qui se fait attendre).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par Alex . Évalué à 2.
Les points de restauration ? ca ne marche pas vraiment (en tout cas chez moi ça n'a jamais marché comme j'en aurai eu le besoin)
dailleurs que snapshot t'il ?
Mais en effet c'est une fonctionnalité qui manque sous linux
[^] # Re: Mon avis personnel
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu fais de la même manière qu'avec des logs "texte" : tu utilises l'outil correspondant au format.
Rappel : AUCUN format n'est lisible par l'être humain. C'est TOUJOURS du binaire, avec un logiciel pour lire. Tu utilises actuellement cat de on ne sait où. Tu utilises plus tard journact venant de EXACTEMENT le même endroit.
Ta vie ne change pas.
Parce que la, la personne qui se plaint est la même qui dirait il y a 10 ans que le log est en UTF-8 (un nouveau format binaire) et que son logiciel dans son mode rescue ne lit que Latin-1 (un autre format binaire), et qu'on aurait dû rester en Latin-1 à cause de ça. Avec ce genre d'argument, on n'avance jamais. Bref, conneries.
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à -3.
Tu cherches à entrer dans le livre guinness des records, section mauvaise foi, c’est ça ?
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 4.
Tu cherches à entrer dans le livre guinness des records, section condescendance_en_manque_d'arguments, c’est ça ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 3.
En manque d’arguments ?
Tu as totalement raison : quand on me prétend qu’UTF-8 est un format binaire et est moins universel que le format binaire spécifique de journalctl, j’ai tendance à avoir du mal à trouver quoi répondre. Bon, c’est surtout que lorsqu’on arrive à un tel niveau de mauvaise foi, je considère que c’est pas la peine de me fatiguer à essayer d’argumenter proprement…
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à -1.
Je n'ai jamais prétendu ça.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 3.
Alors pourquoi viens-tu défendre Zenitram quand il vient dire « UTF-8 est un format binaire » ?
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 0.
Mais quel format n'est pas binaire, enfin ?!
Par contre, dire que l'UTF-8, même limité aux logs, est moins rencontré que le format binaire de journald, j'aimerais savoir où je l'ai dit.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 6.
soupir
Binaire comme opposé à textuel. Il faut que je définisse « format textuel » aussi ? Honnêtement je n’ai pas envie de réécrire un dictionnaire informatique pour le plaisir de la dispute. Ceux avec un strict minimum de bonne foi auront compris, ou alors on est pas de la même espèce et nos schéma de pensée sont tellement différents que ça sert à rien d’essayer de communiquer…
Je ne vois pas comment interpréter autrement la contradiction que tu m’as apporté ici. Mais je peux avoir mal compris, ça m’arrive aussi (souvent même).
[^] # Re: Mon avis personnel
Posté par Shuba . Évalué à 2.
Juste pour info, le format du journal a beau être binaire, il est quand même constitué de pas mal de texte. Par exemple, sur un live-cd fedora:
cd /var/log/journal/long_hash_name
strings system.journal | less
Me renvoie beaucoup d'informations textuelles. Je ne vais pas prétendre que c'est pratique ainsi, ce n'est pas fait pour ça, mais ça montre que ce n'est pas parce que les logs sont binaires qu'ils sont nécessairement cryptiques et complétement impossibles à lire avec les outils habituels.
[^] # Re: Mon avis personnel
Posté par pasBill pasGates . Évalué à 5.
Ton pote chinois qui a son son log en UTF-8 avec des caracteres qui prennent 2 ou 3 bytes, il va le lire comment son log exactement ?
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à -3.
Il fait comme moi, s'il veut faire de l'admin il apprend l'anglais.
[^] # Re: Mon avis personnel
Posté par Renault (site web personnel) . Évalué à 2.
Ça c'est de l'impérialisme occidental comme on aime.
Tu crois que tous les logs des serveurs de France sont en anglais ? Pourquoi est-ce que les chinois pour des activités locales ne pourraient pas utiliser leur langue natale ?
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à 0.
N'importe quoi. C'est juste une conséquence d'un fait :
1 les plus gros éditeurs de softs sont américains
2 la plupart des softs sont développés en anglais, avec des logs en anglais, des commentaires en anglais, etc …
Donc si tu veux faire de l'admin et que tu n'es pas capable de lire l'anglais, tu es mort. Il n'y a qu'à regarder les logs du noyau par exemple qui sont en anglais pour la plupart.
[^] # Re: Mon avis personnel
Posté par Renault (site web personnel) . Évalué à 6.
Et ? Tu crois que l'éditeur de logiciels chinois pour une vente purement chinoise se préoccupe de l'existence d'éditeurs de logiciels américains ?
Tu as bien dis la plupart, cela signifie que c'est n'est pas toujours le cas. Et ce que ce soit pour des petits projets persos, des LL ou des entreprises, je t'assure que du code dans toutes les langues avec les commentaires et les logs associés ça existe dans la vraie vie en production.
Merde, si je commente en français cela signifie que je ne sais pas lire l'anglais.
C'est un raccourcis bien courant et pourtant bien faux qu'on rencontre souvent. Non en informatique il n'est pas nécessaire d'être une tronche en anglais pour réussir, il suffit de savoir lire des manuels techniques (ce qui est bien plus simple). Puis personnellement se je code/commente/log en français c'est parce que je m'exprime plus facilement dans ma langue natale et que je perds moins de temps à réfléchir à ce sujet.
Des produits non internationaux, et qui n'ont pas la préoccupation de la langue universelle, se contente bien de produire le contenu dans la langue natale et pas en anglais dont les logs pour des raisons de conforts et de facilité.
Mais bon, si pour toi informatique = anglais systématiquement, je crois que Lennart est un ange niveau impérialisme à côté de toi.
[^] # Re: Mon avis personnel
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Peut-être qu'utiliser systématiquement l'anglais dans le produit est un gage de pérennité et signifie "on est prêt éventuellement à s'ouvrir à l'international, on aura pas à repasser partout comme ceux qui doivent dégager l'allemand des sources de libreoffice" ?
[^] # Re: Mon avis personnel
Posté par Renault (site web personnel) . Évalué à 5.
Bah alors, pourquoi tu parles français ici. Sait-on jamais, un jour linuxfr deviendra anglophone et nos commentaires pourraient être lus par le monde entier !
En partant de ce principe là, sincèrement, c'est la mort des langues nationales et je ne suis pas d'accord. L'anglais ne doit pas être une règle dite systématique en informatique. Dans certains cas ça se justifie, pas loin d'être le cas de tous.
Car vraiment des phrases du type "il ne doit pas utiliser sa langue pour cet usage" n'est pas une argumentation très intéressante. Chacun fait comme il l'entend et c'est selon moi le plus important plutôt que d'essayer d'imposer sa vision des choses au reste du monde.
[^] # Re: Mon avis personnel
Posté par Guillaume Denry (site web personnel) . Évalué à 5. Dernière modification le 14 février 2014 à 09:32.
Je ne pense pas qu'on puisse comparer les commentaires d'un site francophone (dont la vocation est d'être un espace d'expression spécifiquement francophone) aux commentaires qu'on peut trouver dans un produit qui en général ne s'attache pas vraiment à la langue de l'environnement et surtout, qui a une forte valeur de capitalisation et de ré-utilisabilité et dont on aurait bien du mal à définir le périmètre linguistique dans un avenir à moyen et long terme.
Mais je t'avoue que mon avis sur l'anglais dans le code source (puisque je pense à ça principalement) est loin d'être ferme et définitif, je suis également tiraillé par mon affection pour ma langue natale et plus généralement, par la diversité linguistique de notre monde. Et en effet, si l'on sait qu'un produit n'est définitivement pas destiné à sortir d'un environnement mono-linguistique, autant profiter pleinement du bénéfice de la langue natale. Malheureusement, dans un monde de plus en plus mondialisé, je pense que ces cas là deviennent relativement de niche.
[^] # Re: Mon avis personnel
Posté par khivapia . Évalué à 4.
Et ? Tu crois que l'éditeur de logiciels chinois pour une vente purement chinoise se préoccupe de l'existence d'éditeurs de logiciels américains ?
Bien sûr que oui : de qui le vendeur de logiciels chinois pirate-t-il le logiciel original, sinon à un éditeur américain ?
-----------> []
[^] # Re: Mon avis personnel
Posté par khivapia . Évalué à 0.
Et ? Tu crois que l'éditeur de logiciels chinois pour une vente purement chinoise se préoccupe de l'existence d'éditeurs de logiciels américains ?
Ben on imagine que l'éditeur de logiciels chinois utilise un langage avec des mots-clefs (et possiblement une documentation si elle n'a pas été traduite, ce qui est relativement rare tout de même) empruntés à l'anglais, au hasard, "if, then, else, for, while, do, auto, const/final, let, function, begin/end…" et j'en passe.
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 6.
Ah ! Ah ! Pour combien de temps ? La suprématie américaine n'est plus ce qu'elle était et si dans notre petit coin occidental, ça ne se voit pas la Chine se développe énormément en informatique en matériel (Lenovo à presque racheté tout ce qui était grand publique dans IBM) qu'en logiciel et service (comme gadugadu). Ce que tu vois comme énorme ici n'existe presque pas là bas et inversement. Donc ce sont des affirmations fausses.
Pour ce qui est du problème des log, il arrive que l'appli ai des problèmes à cause de données métier et donc écrive ces données métiers dans ses log potentiellement dans la langue du pays.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par Tibo cocoecolo (site web personnel) . Évalué à 1.
Tu ne confondrais pas Gadu-Gadu (messagerie instantanée polonaise mais appartenant au Sud-Africain Naspers) avec Renren (le « facebook » chinois) par hasard ?
[^] # Re: Mon avis personnel
Posté par Maclag . Évalué à 4.
Ouch.
La Chine monte en puissance. S'ils ont le même raisonnement que toi, à ta place, je m'y mettrais tout de suite!
Il faut quelques années pour savoir lire un peu le Chinois!
[^] # Re: Mon avis personnel
Posté par pasBill pasGates . Évalué à 2.
Ca va pas l'aider beaucoup si le soft dont il doit lire les logs a ete ecrit par une boite chinoise qui logge en chinois.
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à 2.
Marrant ça. il y a pas longtemps certains se plaignaient ici des commentaires en allemand dans LibreOffice … ;)
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 3.
C'est contraignant mais ça existe, donc ce n'est pas à ignorer.
On peut se plaindre du fait que les FS puissent nous renvoyer des erreurs (disque pleins, problèmes de droits,…), mais c'est pas pour ça qu'il faut les ignorer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par groumly . Évalué à 10.
Et toi, tu fais comme moi, si tu veux faire de l'admin, t'apprend systemd.
Ca marche dans les deux sens mon canard, hein.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mon avis personnel
Posté par ookaze . Évalué à 5.
Sans compter que des daemons comme rsyslog savent utiliser les API de systemd pour ceux qui veulent des logs texte.
Même les logs du noyau que l'on ne perd plus grâce à journald.
Et des logs encore plus précises grâce aux informations supplémentaires ajoutées dans le noyau Linux grâce à journald, et les infos supplémentaires que journalise journald.
Je ne comprends pas ces discussion qui ne servent à rien, vu que les gens qui en avaient besoin et qui utilisent réellement systemd ont déjà demandé tout ça et l'ont déjà obtenu.
[^] # Re: Mon avis personnel
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Non, ça c'est des conneries. Les logs, c'est essentiellement de l'ASCII, les caractères hors de l'ASCII y sont largement minoritaire. Avec un logiciel qui interprète tout comme du latin-1, c'est à la rigueur moche, mais pas du tout inutilisable.
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 10.
Il y a un moment où il faut arrêter… La situation « catastrophe plus rien ne marche, mais il faut que je regarde les log avec des outils que j'aurais moi-même réécris parce que plus rien ne marche » c'est pas un cas d'usage et c'est pas compatible avec la gestion de très gros volumes de logs potentiellement centralisés, sauvegardé et analysé sur une machine différente de celle qui les produits qui est un cas d'usage largement répandu.
Au passage pour ceux qui ont peur des situations de crises hollywoodiennes vous devriez être content de pouvoir avoir les logs très tôt dans le démarrage de la machine :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à -1.
T'as déjà fait de l'admin ? J'ai l'impression que non. Quand tu as un KVM distant (style bladecenter par exemple), ca pose pas trop de problème. Mais ce genre de truc n'est pas toujours disponible. Faire des aller-retour entre le bureau et la salle machine est inimaginable. En plus de ça, rien ne dit que ta machine de log aura récupéré les dernières logs, et manque de bol cette log t'apprendra peut-être pourquoi ta machine a planté.
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 3.
Donc tu as toujours un accès distant, qu'est-ce qui t'empêche de rapatrier les logs en question ? On parle comme tu le dis des logs qui ne seraient pas envoyés au serveur de log, donc ça ne représente pas des volumes si gigantesques.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par groumly . Évalué à 10.
Nan mais attends, tu te rends pas compte!
Si ya un rat qui bouffe juste une partie des cables réseaux et que y'a une perte de paquet, en meme temps qu'une variation du champ magnétique de la terre qui corromps le fichier sur le disque dure, ca marche plus non plus!
Pis si tu veux parser le fichier de log sur la redhat 4.2 qui fait tourner linux 0.2.1 de 1993 installe sur le 486dx au fond du bureau, ben tu peux pas non plus.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mon avis personnel
Posté par Alex . Évalué à 1.
l'accès distant peut être sur une kvm, la db de log corrompue, le fichier texte reste un fallback intéressant (même si corrompue on peut espérer qu'une partie de données soit facilement analysable par un humain)
cest des cas critiques et rare, mais loin d'être négligeables
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 3.
J'ai rien compris.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par Alex . Évalué à 2.
ce que je dis, cest qu'un sortie texte en plus de la base de journald me semble nécessaire, même si elle ne contient pas toutes les infos, même si elle est moins pratique à trier. C'est un secours en cas de problème avec la base de journald.
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 1.
Tu veux dire qu'un fichier texte a moins de chance d'être corrompu que le format binaire de journald ? C'est possible. Sans passer par de la redondance disques je pense qu'il pourrait être pas mal pour ce genre de cas de faire des archives par, mais je n'ai jamais vu ce genre de solutions en flux et je ne connais pas journald pour savoir si c'est possible de l'ajouter. Bien sûr on est que dans l'hypothèse, mais je pense que passer par une représentation des données compact puis passer par par permet d'avoir quelque chose de plus fiable.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par Alex . Évalué à 2.
Ou plus facilement récupérable
l'idée de par est intéressante, mais peut on l'utiliser directement sur un flux ? sil il faut refaire un par à chaque ligne rajoutée ça peut faire lourd
[^] # Re: Mon avis personnel
Posté par claudex . Évalué à 3.
Dans ce cas, tu as encore toutes les bibliothèques utilisées par SSH, ça en fait un paquet.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mon avis personnel
Posté par Alex . Évalué à -1.
le fait est cest que l'outil me permettant de lire le format texte existe sur toutes les plateformes, et j'y plus facilement accès dans un cas au limite (crash du disque, corruption des données écrites, plantage du système, etc…)
[^] # Re: Mon avis personnel
Posté par Zenitram (site web personnel) . Évalué à 8.
Avant la démocratisation de UTF8, il y avait pas d'outil pour les "autres plateformes".
argument bidon.
Si tu as besoin d'un lecteur journald sous Windows, il peut être fait, rien ne te l'empèche.
Encore une fois, c'est exactement comme les gens qui se plaigent de UTF8 contre latin9 (mais rempalçons Latin9 par du Japonais pour casser l'argument "je peux lire de l'UTF8 avec un lecteur ASCII, hop les japonais peuvent pas, point), c'est la classique résistance au changement dès qu'un nouveau format arrive (surtout que journald peut sortir du texte "comme avant"…)
Au fait, dans vos log, vous savez pour sûr que 3/2 c'est le 2 mars (ou le 3 février, je ne sais plus)? Votre super lecteur ASCII vous le dit certainement… Vous me faites rire avec vos logs textes "lisibles".
[^] # Re: Mon avis personnel
Posté par SaintGermain . Évalué à 9.
Je me pose la question au moins 2-3 fois par semaine ! C'est vraiment pas facile quand tu travailles en environnement international (hors contexte info pour ma part). Du coup les dates après le 13 du mois ont une connotation spéciale pour moi ;-)
J'écris maintenant les dates au format 2014-03-02 partout, et on me regarde de travers. Par contre je n'ai pas encore pris l'habitude de mentionner le fuseau horaire quand je donne rendez-vous mais ça va venir.
Mais bon pour les logs, c'est souvent 2014-03-02 que je vois, et heureusement.
[^] # Re: Mon avis personnel
Posté par Alex . Évalué à 2.
???
Je comprends pas ce que tu veux dire
actuellement je lis mes logs linux (accès en lecture au /var/log) sous windows
Le jour où ça sera fait ok, on en est pas là
quelle résistance ? je trouve ça très bien journald, la question est de savoir si on peut se passer d'un format texte, et actuellement il y a encore un grand nombre de cas où cest utile
En l’occurrence dans mes lors cest marqué March 2 pour le 2 mars
mais ce n'est pas le sujet
je pense que tout le monde voit les apports qu'apporte un base de donnée pour gérer les logs, la question est peut on se passé d'un format texte en plus pour les cas aux limites (corruption de la db, accès par d'autre sys que linux, crash du système etc…)
[^] # Re: Mon avis personnel
Posté par Renault (site web personnel) . Évalué à 4.
Essaye avec Windows 2000 et tu verras si l'UTF-8 il comprend ce que c'est…
C'est bien ce qu'il dit, aujourd'hui Windows le lit car c'est démocratisé, mais il y a eu une période de transition…
Tu peux le faire, le format est documenté.
Mais personne n'est ton esclave pour le faire car toi tu le souhaites.
De nombreux fichiers de logs systèmes ne sont pas formatés précisément et l'ambiguïté peut exister.
Bah si, un texte pur dont rien n'est formalisé peut induire des soucis de compréhensions ce qui est impossible dans une BDD (chaque champ devant être correctement rempli suivant la norme, sinon ça ne peut pas fonctionner contrairement au format textuel où certains s'en foutent car tant que c'est lisible ça leur semble bon).
[^] # Re: Mon avis personnel
Posté par Alex . Évalué à 0.
ben cest degueulasse, mais exploitable
on parle bien de cas aux limites
ce n'est pas un souhait, cest un cas existant
pour les cas nominaux, évidemment on s'en fout
le format texte, c'est pour les cas aux limites, qui sont rares par définition, mais pas inéxistant et souvent assez critiques
Logiquement non (enfin je suppose) vu que cest journald qui à prioris ca sortir les logs textes, je suppose qu'il garde le même format pour tout
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 2. Dernière modification le 13 février 2014 à 13:57.
Mais tu AS accès aux logs, tout comme avec syslog.
Soit depuis le système en question, soit depuis un autre système (une session Live par exemple) :
man journalctl
--directory=, -D
Takes an absolute directory path as argument. If specified journalctl will operate on
the specified journal directory instead of the default runtime and system journal
paths.
ForwardToSyslog=yes - si ce n'est pas déjà fait, et :
systemctl enable syslog-ng && systemctl start syslog-ng
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par zul (site web personnel) . Évalué à -3.
Oui, encore faut il que ton autre système ait une implémentation de systemd valide (et compatible pour peu qu'ils cassent le format du journal). Alors que tout système doit avoir un truc capable d'afficher un fichier texte.
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 6.
Ça n'a rien à voir avec systemd, mais avec journald.
Quant au format des fichiers de journald, c'est documenté depuis au moins un an et demi, et stable.
soupir Y'en a qui aiment éviter de comprendre ForwardToSyslog=yes….
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par zul (site web personnel) . Évalué à -5.
journald est un sous morceau de systemd avec plein de dépendances qui vont bien. À noter le "Reimplementable Independently" : "maybe" pour journald dans
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
Enfin, les promesses n'engagent que ceux qui les croient :)
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 7.
Donc ta plus d'arguments à part dire : « lui je l'aime pas » ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par zul (site web personnel) . Évalué à -1.
Marrant, je n'ai à aucun moment bashé systemd. Je répondais juste aux assertions de xcomcmdr.
Je n'ai rien contre systemd, je m'en fiche. Je travaille sur des Ubuntu au boulot, et je fais du NetBSD chez moi. Y'a déjà tellement de choses de Gnome qui ne marche pas sur NetBSD qu'un peu plus, un peu moins, ça ne changera pas ma vie. D'autres linuxeries m'embêtent plus que systemd, même si à terme, ça fait peur :D
Pour les logs binaires, je comprend parfaitement les raisons. À mon niveau local, les logs textes sont largement suffisants, mais je comprends que pour des admins systèmes sur des plateformes larges, l'analyse de logs textes doit être rapidement limitante et qu'utiliser un outil spécialisé pour trier / parser des logs binaires est clairement plus efficace. Différents besoins, différents outils.
[^] # Re: Mon avis personnel
Posté par groumly . Évalué à 10.
raaah, ca va quoi.
Les cas d'usages a la con "mais si un rayon cosmique est en opposition avec les chaussettes de l'archiduchesse juste au moment ou je met a jour la libc, je suis dans la merde". Ben ouais, t'es dans la merde. Avec syslog tu seras a peu près autant dans la merde.
Deal with it, c'est pour ca qu'on te paye.
C'est plutôt simple au final:
- ta machine est complètement en vrac t'es dans la merde. va falloir lever ton cul et aller au DC, désolé. 1 partout.
- ta machine marchotte, et t'as donc accès a un set de commande de survie. journalctl en fera partie. Un problème FS qui affect journald affectera aussi syslog. 1 partout.
- ta machine marche, et t'as journald. Arrete de chouinasser et fait ton taff.
Pas de quoi fouetter un chat.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mon avis personnel
Posté par gnumdk (site web personnel) . Évalué à 10.
ForwardToSyslog=yes
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à 3.
OK, donc un point de moins dans les inconvénients de systemd. Peut-être qu'à la fin je finirai par ne plus le détester … :)
[^] # Re: Mon avis personnel
Posté par needs . Évalué à -5.
Tu noteras que pour avoir les mêmes fonctionnalités, il y a maintenant une surcouche. Certains considèrent que ça revient au même, pas moi.
[^] # Re: Mon avis personnel
Posté par Zenitram (site web personnel) . Évalué à 1.
Tu veux dire qu'au bout du dixième journal avec le même "argument" pourrie et avec la même réponse, tu décides qu'enfin tu vas écouter les gens qui te répondent pour la dixième fois la même réponse?
Bref, ça montre clairement que ceux qui critiquent systemd ne le connaissent pas en fait, et que leurs "arguments" sont tout sauf valides.
[^] # Re: Mon avis personnel
Posté par brendel . Évalué à -1.
Je ne trouve pas que ça montre ce que tu dis moi.
[^] # Re: Mon avis personnel
Posté par Astaoth . Évalué à 1.
Ca montre surtout que ceux qui critiquent ne suivent pas tout les débats/troll autour de journald/systemd.
En revanche, leurs arguments peuvent être valides, bien plus que les tiens quand tu ne te contentes que de contre-argumentation d'ailleurs, tant qu'ils ne savent pas que leur problème a une solution.
Emacs le fait depuis 30 ans.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mon avis personnel
Posté par flagos . Évalué à 0.
Qydlc3QgdnJhaSBxdWUgYydlc3QgZXh0cmVtZW1lbnQgcHJhdGlxdWUuIE9uIHBvdXJyYWl0IGZh
aXJlIHBhcmVpbCBhdmVjIGxlcyBmaWNoaWVycyBkZSBjb25maWcgZGFucyAvZXRjLy4gUG91ciBn
YWduZXIgZGUgbGEgcGxhY2UgYmllbiBzdXIuIEF2ZWMgdW4gYWxnbyBkaWZm6XJlbnQgYSBjaGFx
dWUgZm9pcyBzaW5vbiBjJ2VzdCBwYXMgZHJvbGUuCg==
[^] # Re: Mon avis personnel
Posté par JJD . Évalué à 6.
Put… tu t'est planté :
Ton commentaire est en ISO-8859-15 alors que le site est en UTF-8 !!
[^] # Re: Mon avis personnel
Posté par Thomas Debesse (site web personnel) . Évalué à 1.
PiBzaW5vbiBjJ2VzdCBwYXMgZHJvbGUK
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Mon avis personnel
Posté par Emmanuel C . Évalué à 10.
Tu confond clairement format de stockage et représentation à l'affichage. Il se trouve que tu n'accèdes jamais directement à tes logs en inspectant ton disque dur au moyen d'un microscope, mais que tu passes par un outil, fut-il aussi rudimentaire que "cat". Moi, j'utilise "less" ou "tail". Dans les deux cas, ces outils interprètent le contenu de ton fichier (dit "texte", mais le format texte n'est qu'un sous ensemble des formats binaires possibles) pour te le formater correctement à l'écran : typiquement, les octets de valeur 10 sont représentés par un passage à la ligne suivante de ton dispositif d'affichage.
journald permet de faire une interprétation différente de ses logs pour, comme d'autres outils, les restituer de manière compréhensible à l'écran, ou plus simplement pour les convertir dans un autre format (comme le format texte).
La plupart des outils cités plus haut gère parfaitement la lecture de données en provenance d'un tube, notamment quand tu veux paginer la sortie d'un exécutable. De plus, certains outils te permettent de faire des recherches dans ce flux. Il suffira de piper la sortie de journald vers ton outil préféré.
Admet que c'est tout de même plus pratique que de devoir copier coller ton message du navigateur vers base64… Si linuxfr veux transmettre les messages en base 64 puis les décoder à la volée en javascript, ma foi, pourquoi pas.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1. Dernière modification le 12 février 2014 à 14:31.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 8.
Le format texte, ça ne veut rien dire. C'est un format binaire, avec un encodage spécifique.
There Ain't No Such Thing As Plain Text.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par Spack . Évalué à 3.
La principale différence avec toute autre forme binaire c'est qu'une fois décodé, le résultat est une suite de caractères compréhensible par l'homme, là où un format purement binaire nécessite le support d'un logiciel qui formatera l'affichage pour les présenter… Bon, OK c'est aussi le cas du format texte… Mouarf, je suis perdu.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mon avis personnel
Posté par jben . Évalué à 10. Dernière modification le 12 février 2014 à 18:40.
Alors voyons voir… sur une machine sans journald
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]
[^] # Re: Mon avis personnel
Posté par khivapia . Évalué à 5.
En général, les logs compressés sont uniquement les plus anciens, qu'on utilise pour audit.
Le cas d'usage présenté ci-dessus (lire les logs les plus récents pour comprendre un problème de démarrage) ne nécessite pas de les décompresser.
[^] # Re: Mon avis personnel
Posté par needs . Évalué à 0. Dernière modification le 12 février 2014 à 20:29.
Ce n'est pas le cas chez moi.
Oula non, ce n'est pas du tout le même niveau de reflexion. Un format binaire n'est pas forcément compressé. La différence est de taille. Dans un cas tu as un format qui est uniquement lisible par un outil, pas forcément disponible à grande échelle, de l'autre tu a un format de fichier (LZ77) lisible sur à peu près tout les Unix qui te tomberont sous la main (de mémoire je crois bien qu'il est aussi possible de décompresser des archives .zip sur MS-DOS). Et comme dit dans un commentaire plus haut, on compresse plutôt les logs anciens.
[^] # Re: Mon avis personnel
Posté par anaseto (site web personnel) . Évalué à 9.
Mais une fois que systemd aura dominé le reste du monde ce ne sera plus vrai…
Plus sérieusement, s'il y a des choses qui me laissent un peu sceptique dans systemd, je trouve que le format des logs on s'en fou un peu du moment qu'il est bien documenté et change pas à chaque nouvelle version. Ce n'est d'ailleurs pas comme s'ils étaient les seuls à faire ce genre de choses : par exemple, les logs du pare-feu PF sont en format binaire, et il faut utiliser tcpdump pour pouvoir les lire, et j'ai jamais lu personne se scandaliser à ce propos.
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 7.
Et comme systemd n’a aucune intention de sortir de Linux, ce ne sera jamais vrai :)
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 4.
On a bien zcat, zgrep, etc on peut créer jcat, jgrep,…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 3. Dernière modification le 13 février 2014 à 11:02.
Tu m’expliques l’intérêt pour FreeBSD, Apple, Microsoft,
SunOracle… d’intégrer j* dans leur OS ?[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 2.
Et si on s'en fout ? MS n'a déjà pas d'outil de base pour gérer les logs de tes unix correctement (pas de bin-utils, pas d'outils pour gérer les gros volumes de logs) donc il suffit que tu fasse comme aujourd'hui avec windows : tu installe les outils qui vont bien pour ton travail.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Je pense que l'argument était que le texte était un format standard, tout comme la compression gzip, tandis que le format de journald n'avait rien d'un standard.
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 2.
Peut être qu'un format à la lumberjack aurait été plus générique, mais la perte de performance ce serait à mon avis pas mal fait sentir.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 1.
Il suffit de documenter le format binaire de journald (si ce n'est pas déjà fait)
Et le format texte, c'est un standard de fait (hier ASCII, aujourd'hui UTF-8). On remplace ça par un autre standard de fait (le format de fichier des logs de journald - qui apporte pas mal d'avantages), sans interdire les anciens usages (grâce à syslog-ng).
Y'a pas de quoi réagir de cette manière.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 2.
Bonne chance pour l’imposer au reste du monde informatique, on te regarde de loin et on en reparle quand tu auras réussi :)
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 1.
Tiens, 100% de condescendance, 0% d'arguments. Sur linuxfr. Bizarre. ;-)
Si tu veux savoir, systemd est déjà adopté par beaucoup de distributions majeures (y compris Debian pour bientôt, on dirait), faut croire que ça plaît d'éviter 10 000 formats de logs différents. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 4.
Je ne vois aucune condescendance.
Mon affirmation de base est que UTF-8 est universel, supporté de base dans tous les langages, OS et toolchains modernes. Et toi tu me réponds « yaka faire du format de journald un standard de fait tout aussi universel » ? Mais tu sais, « universel », ça ne se résume pas à « l’ensemble des distributions Linux qui ont adopté systemd » hein…
[^] # Re: Mon avis personnel
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Surtout que, systemd n'a jamais eu de vocation à prendre en charge quoi que ce soit d'autre que Linux.
Donc on a :
[^] # Re: Mon avis personnel
Posté par Maclag . Évalué à 9.
Un peu comme l'ext4 ou le btrfs, donc finalement on ne pourra pas lire les logs texte non plus depuis une machine non-Linux.
Euh… une minute!
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 3.
Je peux lire de l’ext depuis BSD et Windows. Probablement OSX aussi.
[^] # Re: Mon avis personnel
Posté par Le Gab . Évalué à 4.
Tu pourrais aussi surtout recompiler les outils d'analyse de systemd (ex journalct) pour Windows, BSD et OSX.
Ça sera infiniment plus simple que de porter un FS. :)
Mais bon, n'inventez pas des cas de figures tordus, si vous devez recourir à ce genre de contorsions sur des systèmes modernes, c'est sur un autre point qu'il faudrait commencer à se poser des questions.
Je ne suis pas défenseur de systemd ni spécialement détracteur mais les faits sont là, il est l'élu, des gars techniquement plus brillants que moi le soutiennent et à priori.
[^] # Re: Mon avis personnel
Posté par Maclag . Évalué à 8.
C'est exactement ce que j'essaie de te dire:
Je lis qu'aucun système ne pourra jamais lire les logs de journald parce que les autres systèmes n'en ont pas besoin.
OS X n'a pas besoin de ext4, mais on peut quand même lire de l'ext4 depuis OS X.
Windows n'a pas besoin de l'ext4, mais on peut quand même lire de l'ext4 depuis Windows.
BSD n'a pas besoin de l'ext4, mais on peut quand même lire de l'ext4 depuis BSD.
journalctl n'existe que sous Linux et les autres n'en ont pas besoin.
Oh non! Ça veut dire que personne ne codera jamais un lecteur de log pour les autres systèmes!?
L'histoire nous laisse à penser le contraire!
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 7.
C'est vrai que ça à un intérêt énorme de pouvoir monter une partition ext* depuis Windows grâce à un logiciel tiers, pour lire les logs avec notepad++. Ça arrive tous les jours en entreprise.
Pffff….
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 4. Dernière modification le 13 février 2014 à 14:59.
Tu peux les lire d’une autre machine sous un autre OS à travers un montage réseau aussi. Je n’ai pas assez de recul pour juger si c’est très rare ou pas, mais en tout cas ça m’est déjà arrivé dans ma carrière qui n’est pourtant pas très longue.
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 10.
Ça fait un an et demi que c'est fait.
Surtout qu'il n'y a pas un standard de texte mais des standards. En occident on utilise que l'ascii et utf8, mais bon rien n'interdit d'utiliser un autre unicode ou un autre format iso. Même ascii c'est déjà multiple. Ajoute à ça qu'utf8 est une merde pour les log (l'encodage des caractères à taille variable c'est pas très pratique pour le traitement des log, il faut ajouter une indexation) et que par dessus ces standards on a des standard de fait avec le format syslog, celui par défaut de log4j, etc et qu'on mixe tout ça avec les standards de format de date.
Donc oui les logs aujourd'hui c'est standard un peu trop, voir beaucoup trop pour que ce soit agréable à utiliser, mais comme une fois qu'on a commencé à préparer des lasagnes on en est plus à une couche près on ajoute une couche qui va harmoniser tout ça (oui oui on utilise un truc pas standard pour uniformiser quelque chose de standard).
journald propose quelque chose de plus harmonieux, tout en proposant de s'interfacer avec l'existant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 3.
Heu, il y a des équivalents de cat et de less (dont j’ai oublié le nom) dans les OS Microsoft depuis MS-DOS 6.0 hein…
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 2.
Moi je ne les connais, mais c'est pas grave on s'en fout je n'utilise pas windows, par contre c'est dommage que les gens que j'ai vu travailler avec des logs de 500Mio sous Windows ne les connaissent pas et en soit arriver à chercher sur google une solution qui leur faisait installer des logiciels supplémentaires.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par Frank-N-Furter . Évalué à 3.
brew install j* pour ceux qui en ont besoin sous OS X.
J’vois pas ou est le problème, ceux pour qui le fonctionnement de journald pose problème peuvent rediriger le tout vers syslog.
Depending on the time of day, the French go either way.
[^] # Re: Mon avis personnel
Posté par pasBill pasGates . Évalué à 7.
LOL
Et ton log en format texte, tu le lis avec tes yeux rives sur les electrons du disque dur ?
cat, tail et less c'est quoi si ce n'est des outils ?
Je pourrais te mettre une machine Linux avec des logs en format binaire, et des outils nommes cat, tail, less qui te lisent ce format, et tu n'y verrais que du feu.
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 3.
Le mot-clef est « grande échelle », pas « outil ».
[^] # Re: Mon avis personnel
Posté par Renault (site web personnel) . Évalué à 2.
Le nombre de distributions ayant journald et systemd est pourtant suffisamment grand pour que tu puisses t'en sortir de ce point de vue…
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 1. Dernière modification le 13 février 2014 à 10:58.
Et bien entendu le monde se limite aux distributions Linux récentes.
(note aux mal-comprenants : le mot clef est « Linux », pas « récentes »)
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 0. Dernière modification le 12 février 2014 à 19:00.
Une définition bien précise ? Que nenni !
Ton fichier texte (qui est un fichier binaire) peut être encodé en ascii, utf-8, etc… Dire "fichier texte" tout seul ne renseigne en RIEN !
Ah, diantre ! Je croyais que plain text = transparent. On dirait que non. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par gouttegd (site web personnel) . Évalué à 3.
Ah, diantre, la mauvaise foi n’est pas l’apanage des détracteurs de systemd…
Il est vrai que la définition du type MIME
textdit seulement « The "text" media type is intended for sending material which is principally textual in form », sans prendre la peine de définir ce qu’est une « forme textuelle » — probablement parce qu’à part des enculeurs de mouche, personne n’a besoin d’une définition de ce qu’est du texte…Ça n’indique pas l’encodage, certes. Mais ça t’indique bien qu’il s’agit de texte. Que l’information sur l’encodage utilisé doive être précisée à côté (comme dans
text/plain; charset=UTF-8) ne permet pas de dire péremptoirement que le format texte n’existe pas.« Fichier texte » renseigne suffisamment pour savoir que le contenu du fichier est supposé être lisible comme… du texte. Tout comme « fichier audio » renseigne suffisamment pour que je ne tente pas d’ouvrir un tel fichier dans une visionneuse d’images, même sans savoir si c’est du FLAC ou du Vorbis…
Qu’est-ce que tu ne comprends pas dans « without much processing » ?
[^] # Re: Mon avis personnel
Posté par Sufflope (site web personnel) . Évalué à 2.
Et toi, qu'est-ce que tu ne comprends pas dans without much ?
[^] # Re: Mon avis personnel
Posté par Sufflope (site web personnel) . Évalué à 2.
Vous moinssez parce que vous êtes frustrés d'être nul en anglais ?
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 3.
Le fait que le format "texte" a toujours besoin d'être "décodé", tout comme les formats "binaires" (parce qu'il en est un) montre que cette séparation est très artificielle.
Le format binaire du journal de journald, il suffit de le documenter, et on pourra implémenter différents "lecteurs" compatibles. Comme on a documenté les différents types d'encodages.
(et puis franchement, vu qu'on peut activer la copie vers syslog en 3 secondes, l'intérêt de ce n-ième troll sur journald est limité…)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par gouttegd (site web personnel) . Évalué à 10.
Tellement artificielle que le décodage des flux de texte est une fonctionnalité de base dans la plupart des langages de programmation, supportée soit directement dans le langage lui-même, soit dans ce qui lui tient lieu de bibliothèque standard. On ne peut en dire autant d’aucun autre format.¹
Il se trouve même des langages où traiter un flux comme du texte est le comportement par défaut, à moins que l’on ne précise explicitement qu’il faut le traiter comme du binaire.
Il faut une bonne dose de mauvaise foi pour nier le caractère quasi-universel du format texte, et encore plus pour affirmer qu’il n’existe rien de tel qu’un « format texte » parce que ce ne serait qu’un format binaire parmi d’autres. C’est bien un format binaire, oui, mais que l’on met explicitement à part de tout le reste, et ce depuis longtemps. Libre à toi de penser que c’est « artificiel ».
Je ne dis pas le contraire (et j’ai déjà eu l’occasion de dire dans d’autres journaux que le choix d’un format binaire pour journald pouvait se comprendre, même si je n’ai personnellement pas d’avis tranché sur la question). Raison de plus pour ne pas nourrir le troll en sortant des affirmations à l’emporte-pièce comme « le format texte, ça ne veut rien dire ». C’est à ça que je répondais.
¹ Seul le XML peut éventuellement prétendre à un niveau de support (presque) aussi répandu (du moins dans les langages modernes). C’est un format basé sur du texte, quelle coïncidence…
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 1. Dernière modification le 12 février 2014 à 23:52.
Je le maintiens, désolé. Il FAUT savoir l'encodage pour en faire quoi que ce soit.
C'est comme tu disais "tiens, voilà un fichier image". Ok. Quel format ? JPEG, PNG, autre ?
C'est un poil important, quand même.
Ça ok, mais de là à dire qu'un format "binaire" (par opposition au "format texte") est forcément complexe, quand on voit le bordel des encodages de texte, faut arrêter… C'est surtout là où je voulais en venir.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par ckiller . Évalué à 6.
On parle de log, et l'énorme majorité des caractères d'un log sont en ascii
donc, l'encodage du fichier on s'en contre fiche.
Ca n'a rien à voir avec une différence de format entre png et jpg.
Par moment, il faut savoir être honnête.
oui, parce que figure toi, que tout les fichiers générés ne sont pas des logs.
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à -4.
TU parles de logs.
Et c'est bien parce que gérer l'encodage proprement est largement moins simple que de se limiter à l'ASCII.
Se limiter à un cas simple d'encodage texte ne veut pas dire que seul l'encodage ASCII existe.
(et faut-il aussi ENCORE rappeler l'intérêt du format binaire pour les logs ? Par exemple, pouvoir incorporer des données binaires telles que des core-dumps -, permettre de construire une API stable permettant d'accéder aux données de manière plus pratique plutôt que de bidouiller de la regex et du grep, etc…)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par gouttegd (site web personnel) . Évalué à 2.
Personne ne prétend le contraire. Si je reprends le document que j’ai déjà cité (le RFC 2046), il est bien précisé :
(C’est moi qui souligne.)
Encore une fois, personne n’a prétendu ça (en tout cas pas moi). Le « plain text » est une séquence de caractères. L’encodage desdits caractères ne fait pas partie de la définition (d’où précisément le fait qu’il soit « critical » de le préciser à côté). Une séquence de caractères encodés en UTF-8 est du « plain text » au même titre qu’une séquence de caractères encodés en Latin-1.
Je ne suis définitivement pas d’accord avec cette formulation. Il est dommage qu’elle soit tellement mise en évidence dans ce texte, parce que ce n’est pas le message que l’auteur veut faire passer. Le vrai message serait plutôt quelque chose du genre « Not Everyone Uses ASCII » ou « A Sequence Of Characters Is Not A Sequence Of Bytes ». Là je serais d’accord.
Une image reste une matrice de pixels,¹ indépendemment du format de ceux-ci, tout comme du texte brut reste une séquence de caractères. Manipuler l’image nécessite de connaître son format, évidemment, mais on ne peut pas dire « There Is No Such Thing As Images », simplement parce qu’il existe plusieurs façons de représenter des matrices de pixels.
¹Bon, hors le cas des images vectorielles, je préfère le préciser avant que quelqu’un ne rebondisse là-dessus.
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 9.
Il faut arrêter la fumette (ou la mauvaise foi) parfois. Le standard de fait aujourd’hui c’est utf-8. On parle de journald là, un outil moderne, pas du problème des encodages sur les systèmes antédiluviens qui font tout par défaut en EBCDIC.
Aujourd’hui, quelque chose « encodé » en UTF-8 est universel, lisible par tous les systèmes qui ont moins de 10 ans, supporté par absolument tous les langages et tous les outils vaguement maintenus. Prétendre le contraire c’est juste un gros troll même pas drôle.
[^] # Re: Mon avis personnel
Posté par Maclag . Évalué à 4.
Question subsidiaire:
Quand l'encodage UTF-8 a commencé à se démocratiser, combien ont hurlé que UTF-8, c'est pas assez répandu alors que l'ASCII, on peut le lire sur n'importe quelle machine qui nous tombe sous la main?
Tu mentionnes toute machine qui a moins de 10ans peut le lire. Je te parie que d'ici 10ans il n'existera aucune système sur lequel un lecteur de log journald ne sera pas disponible!
Les langages de programmation? Ils auront leur bibliothèque, tout comme ils ont tous une bibliothèque XML.
Les systèmes alternatifs? Aussi bien sûr! Et que ceux qui disent qu'ils n'en ont pas besoin/n'en veulent pas viennent m'expliquer pourquoi on peut lire les partitions FreeBSD depuis Linux et vice-versa.
Tiens, c'est d'ailleurs un autre point à soulever ça. Pas sur ce commentaire, mais ailleurs dans les fils: si on récupère les logs d'un serveur dont les bibliothèques sont en carafe depuis une machine non-Linux, on ne peut pas lire les logs!
Et les outils n'existeront pas de la même manière qu'il sera impossible de lire une partition ext4 depuis un système non-Linux. Du coup je suis plutôt optimiste…
[^] # Re: Mon avis personnel
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Sauf qu'encore une fois, systemd et journald n'ont pas et n'ont jamais eu de vocation à l'universalité.
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 4.
N’importe quelle machine qui peut lire de l’ASCII peut lire de l’UTF-8, sauf les caractères non-ASCII (mais comme de toute façon ils sont pas représentables OSEF). C’est d’ailleurs cette compatibilité qui a fait la force d’UTF-8 (au début UTF-16 était pas mal poussé et certains pensaient que UTF-8 serait là uniquement pour la transition, mais bizarrement personne n’en voulait…)
Je n’ai pas de boule de cristal, mais ça m’étonnerait énormément. Le format de journald est spécifique à :
quel mainteneur d’une librairie standard d’un langage voudrait prendre du temps pour ça, honnêtement ? La seule raison pour laquelle le format de journald arriverait dans les librairies standard d’un langage serait que ce format soit universellement adopté, de Microsoft à Apple en passant par les BSD. Les chances pour que ça arrive sont proches de 0 à mon avis.
Faire du format binaire spécifique avait du sens quand les librairies standard des langages tendaient à être anémiques et n’apportaient pas grand chose de réutilisable à quelqu’un qui voulait définir un nouveau format. Aujourd’hui l’usage a changé : les librairies standards tendent à essayer de couvrir de plus en plus d’usages avec quelques formats génériques (JSON, XML, zlib) mais qui peuvent couvrir quasiment tous les besoins. Aujourd’hui avec la lib standard de Python je peux gérer facilement des web-services (99% sont en JSON ou XML), des documents bureautiques (les deux formats dominants, OOXML et ODF sont juste des fichiers zip contenant des fichiers XML), des logiciels (idem pour les .jar, .apk, .ipa ou les extensions Firefox). En fait, à part les fichiers multimedia (video/audio/image), à peu près tous les fichiers que je manipule au jour le jour sont facilement « scriptables » (i.e. lisibles facilement en quelques lignes de Python en utilisant juste les outils fournis par sa lib standard). Ce que je ne me prive pas de faire, du reste. Je parle de Python, mais ça s’applique dans à peu près tous les autres langages.
C’est en regard de ces faits là que quand je vois quelqu’un réinventer la roue avec un nouveau format binaire spécifique, je tique. Pourquoi refuser de s’appuyer sur la puissance des librairies standard des langages modernes ? Un nouveau format binaire spécifique en 2014, ça ne m’inspire qu’une chose : un type excentrique sur son îlot qui s’amuse à définir une nouvelle langue à partir d’un mélange d’elfique et de klingon.
Alors bien sûr on peut toujours arguer que tous les usages ne sont pas implémentables avec ces 2-3 formats génériques. Ce qui est parfaitement vrai : je vois mal réécrire InnoDB avec juste zlib+xml par exemple. Mais pour moi ça devrait rester l’exception, une exception soigneusement justifiée, et je n’ai jusqu’ici vu absolument aucun argument convainquant justifiant cette exception dans le cadre de journald.
[^] # Re: Mon avis personnel
Posté par Maclag . Évalué à 7.
Ah effectivement, si on parle de la lib standard, je n'y crois pas une seconde. Du coup, je suppose aussi que tu installes le minimum sur les autres machines du parc dont tu pourrais avoir besoin pour lire ces logs.
Mais franchement, si tu me disais que la seule machine à ta disposition qui puisse lire les log journald c'est la machine qui les produit, parce que tu n'as rien installé pour ça ailleurs, je penserais que tu n'as sûrement rien installé non plus ailleurs pour lire les partitions de la machine Linux, du coup les logs textes n'y changeront rien.
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à -1.
Allons, un peu d’imagination :
Alors oui, dans tout ces cas on peut faire autrement, non, ce n’est pas à 100% bloquant.
Maintenant j’aimerais qu’on me donne une bonne raison pour laquelle journald se passe des bienfaits d’être compatible de base avec les libs standards de tous les OS sur tous les langages. Une seule. Ensuite je me tais, promis.
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 3.
Tu exporte les logs dans un format texte via journalctl et tu fait ce que tu veux ?
pas compris ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à -3.
Cool, et quel est donc l'intéret des logs binaires de journald alors ? Ajouter une étape supplémentaire ?
Développer un plugin à sa solution qui lui permettrait d'utiliser les libs systemd pour décoder les logs binaires. Les libs en question sont copyleft et le boss ne veut pas lier son code à du code copyleft.
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 4. Dernière modification le 13 février 2014 à 23:57.
Bordel, ils sont super les anti-systemd !
"On veut des journaux avec des fichiers texte !" -> "Ok voilà : ForwardToSyslog=yes"
"QUOI ? et quel est donc l'intéret des logs binaires de journald alors ? Ajouter une étape supplémentaire ? "
-> " -_-# "
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par barmic . Évalué à 6.
Tu gagne de l'espace disque et tu exporte qu'une partie de tes données (celle dans l'intervalle de temps qui t'intéresse).
Tu a la description du format avec des guides lines sur la manière de gérer le format, tu peut en faire ce que tu veux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mon avis personnel
Posté par Albert_ . Évalué à -1.
Maintenant j’aimerais qu’on me donne une bonne raison pour laquelle journald se passe des bienfaits d’être compatible de base avec les libs standards de tous les OS sur tous les langages. Une seule. Ensuite je me tais, promis.
Ainsi en a decide Poettering. Homme de peu de foi.
[^] # Re: Mon avis personnel
Posté par zebra3 . Évalué à 10.
Bah il est compatible, puisqu'il peux exporter vers Syslog.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Mon avis personnel
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 3.
Et en json, et en text, et …
[^] # Re: Mon avis personnel
Posté par Alex . Évalué à 2.
en temps réel ?
sinon cela ne présente pas le même intérêt que l'export syslog
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 2.
Bah déjà, il n'est pas incompatible. Il suffit d'activer la copie des messages vers syslog. A moins que syslog ne soit pas fiable ? ;-)
À part ça, il y en a plein. Comme éviter que le journal soit altéré par quelqu'un s'étant introduit frauduleusement dans le système et qui essaie d'effacer ses traces. C'est bien plus simple quand le journal est sous forme textuel (y'a plein d'outils pour ça), et que la seule authentification se limite à être root pour pouvoire le faire.
Il y a aussi le fait de pouvoir incorporer des données binaires avec le message de log en question (données SMART, core dumps, des blob firmware, …).
Le journal est aussi entièrement indexé, chaque information est dans un champ à part.
Bref, t'es en train de me faire décrire tous les avantages d'une base de donnée sur du texte, là. Je pense que tu devrais déjà être au courant…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par Alex . Évalué à 1.
S'en même s'être introduit, il me semble que journald peut signer les journaux, alors qu'avec un serveur syslog on peut écrire n'importe quoi en faisant croire que ça vient de n'importe où (ceci dit je bifurque, cela n'a rien à voir avec le troll texte vs db)
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 2.
Les arguments de ce lien ont déjà été discuté dans un précédent journal (ou dépêche ?). Rien de tout ça ne nécessite un format binaire.
Aucun problème pour signer du texte par exemple (GPG pour les mails ça marche très bien…)
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 2.
Et bientôt, tu vas me dire que dans ton fichier texte, on a des champs bien séparés, avec notamment des dates dont le format ne varie pas… euh, non rien.
Et bientôt, tu vas me dire que ton fichier texte est entièremeent indexé… euh, non rien.
Etc…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par Moonz . Évalué à 1.
On va pas refaire le débat, mais tout ça nécessite de la structure, pas du binaire, et il est tout à faire possible de structurer du texte.
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 8. Dernière modification le 13 février 2014 à 21:24.
Ah ben oui la preuve : chaque logiciel a une structure de log textuel qui est la sienne. SUPER.
En des décennies, on a pas été foutu de standardiser un minimum tout ça. Même pas au niveau des dates. Ça suffit les conneries.
Donc non, il y a des raisons claires, précises, et valables pour le format "binaire" de systemd, qui ont été expliquées mille fois. Dire "on peut le faire avec du texte", alors que ça n'a jamais été fait n'est pas un argument.
Dire pour tout cas "on peut le faire avec du texte", c'est le cas classique du mec qui a un marteau et pour qui chaque problème ressemble à un clou.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Et pourtant si : Le format Syslog.
[^] # Re: Mon avis personnel
Posté par groumly . Évalué à 5.
Ah oui, on peut.
Et c'est super performant, du XML ou des objets JSON de plusieurs dizaine/centaine de mega octets.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mon avis personnel
Posté par zebra3 . Évalué à 10.
Bravo, tu viens de démontrer que n'importe quelle machine qui peut lire de l'ASCII peut lire de l'ASCII :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Mon avis personnel
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Sans indication du codage, il y a tout de même une heuristique extrêmement simple pour utiliser un fichier texte, surtout un log :
[^] # Re: Mon avis personnel
Posté par Le Gab . Évalué à 2.
Oui mais à la base, il n'y a surtout pas besoin de recourir à une heuristique vu que le format binaire de systemd est libre ou issu d'un logiciel libre disons et documenté. :)
[^] # Re: Mon avis personnel
Posté par gnumdk (site web personnel) . Évalué à 10.
Oui, ça s'appelle journald est c'est vraiment un bon produit, qui pour l'instant permet de forwarder vers syslog pour les gens qui préfère le format texte… Et ça permet de faire plein de truc sympa comme:
Bref, moi, entre les services offerts par journalctl et ceux offerts par systemctl, je n'y vois que du mieux…
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à 1.
peux-tu STP me faire un lld sur journalctl ?
Je n'ai pas de distrib avec systemd installé sous la main.
[^] # Re: Mon avis personnel
Posté par gnumdk (site web personnel) . Évalué à 4.
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à -10.
Beurk !!!! :)
[^] # Re: Mon avis personnel
Posté par Renault (site web personnel) . Évalué à 10.
Super, tu vois que journald utilise des fonctions de chiffrement, compression et de traitements d'erreurs que ne font pas les outils textes que tu as cité.
En quoi ça le rend mauvais, lourd ou inutile ? Au contraire, je pense qu'il y a moyen de tirer avantage de tout ceci.
Il y a des logiciels qui ont bien plus de dépendances en terme de bibliothèques, c'est loin d'être un problème ici.
[^] # Re: Mon avis personnel
Posté par totof2000 . Évalué à -1.
Ca peut poser problème dans le cas ou par exemple une mise à jour a foiré (ne pas me dire que ça n'arrive jamais, c'est faux), et que certaines de ces libs sont incohérentes avec le reste du système. Si tu diminues le nombre de libs, tu diminues le risque.
Personnellement ça m'est déjà arrivé de me retrouver avec un serveur sur lequel une mise à jour avait foiré. Ce serveur n'avait pas été redémarré suite à cette mise à jour. certaines libs n'étaient pas à jour et certains services plantaient au démarrage. Il s'est vautré et il a fallu le remettre en marche. Les logs étaient accessible facilement, mais je me demande ce qui se passerait si l'une des libs utilisées par systemd venait à être corrompue, ou incohérente avec le reste du système.
[^] # Re: Mon avis personnel
Posté par gnumdk (site web personnel) . Évalué à 6.
T'as oublié gzip :p
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 9.
C'est décidé, je passe à vi ! ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -8.
J'ai entendu un autre son de cloche, un jour. Quelqu'un qui s'était retrouvé avec journald, et qui avait besoin des logs de son serveur de courrier. Avec la commande appropriée, il lui a fallu trois heures pour récupérer quelques centaines de lignes.
[^] # Re: Mon avis personnel
Posté par gnumdk (site web personnel) . Évalué à 10.
Et moi, j'ai connu un mec qui s'est retrouver avec SysV, il fallait 1 mois, 6 jours et 2 heures à son serveur pour démarrer, quelle grosse merde ce système d'init! :p
Moi aussi je peux raconter n'importe quoi pour valider mes arguments…
[^] # Re: Mon avis personnel
Posté par Fabimaru (site web personnel) . Évalué à 2.
Comment les programmes packagés (plus précisément, les services déclarés dans /etc) vont-ils faire être compatibles avec plusieurs systèmes d'init?
Sur mon Ubuntu, j'ai un mélange de services déclarés à la mode Upstart et à la mode SystemV.
[^] # Re: Mon avis personnel
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6. Dernière modification le 12 février 2014 à 13:05.
En fournissant plusieurs scripts ou descriptions, un par format de système d'init.
Sachant qu'être compatible avec SysV RC, c'est être, de façon minimale, compatible avec à peu près tous les systèmes de lancement de services puisque les systèmes de lancement de services en questions sont compatibles avec les scripts SysV !
[^] # Re: Mon avis personnel
Posté par gnumdk (site web personnel) . Évalué à 4.
Cela ne sera pas vrai longtemps pour KDE, GNOME et compagnie à mon avis…
Après, tout le monde pourra continuer à maintenir les gestionnaires de sessions actuel mais je suis presque sur que dans pas très longtemps, la plupart des environnements de bureau utiliseront systemd pour lancer leur session.
http://www.phoronix.com/scan.php?page=news_item&px=MTEyNjc
[^] # Re: Mon avis personnel
Posté par needs . Évalué à 3.
LOL, y'a même un service pour openbox, tant qu'à faire, pourquoi pas déclarer chaque programme comme un service et n'utiliser que systemd pour les lancer, ça serait classe et tout à fait dans l'esprit du "tout-en-un" !
[^] # Re: Mon avis personnel
Posté par claudex . Évalué à 8.
Tu sais que les DE gèrent déjà un système similaire pour les services liées à la sesssion (par exemple, le dæmon KDE) ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mon avis personnel
Posté par needs . Évalué à 1.
Je ne suis pas sûr de bien comprendre, peux-tu apporter quelques précisions ? Parles-tu d'un programme qui "supervise" le lancement de services au sein du DE ? Si c'est bien cela, ma remarque était plutôt sur le fait de considérer des WM comme des services, alors qu'ils sont très bien géré par le serveur X.
[^] # Re: Mon avis personnel
Posté par claudex . Évalué à 6.
Ça veut dire quoi « très bien géré par le serveur X » ? Parce que si le WM crash, X ne fait rien, systemd permet de le redémarrer, c'est beaucoup plus user-friendly.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mon avis personnel
Posté par needs . Évalué à 0. Dernière modification le 13 février 2014 à 20:35.
J'espère que ce n'est pas la raison principale, car c'est vraiment faire preuve de mauvaise foi.
Une manière de faire cela simplement, dans ton
.xinitrc, remplaces le traditionnel :Tu peux mettre :
Très bien géré par le serveur X, ça veut dire proprement intégré au système, puissant et facilement modifiable. Peux tu en dire autant de
systemd? Pas pour le premier point.[^] # Re: Mon avis personnel
Posté par cedric . Évalué à 5.
Bah, avec systemd mon window manager aura une backtrace genere et directement archive que je pourrais facilement retrouve. Il aura un watchdog qui verifiera que celui-ci est bien toujours actif (protection contre les boucles infinis). Et je peux mettre un certain nombre d'autre restriction.
Enfin, systemd va pouvoir se charger du demarrage de toutes les petites applications au demarrage de ton window manager sans que celui-ci ai a s'en occuper et en offrant les meme options que precedement. En terme de stabilite et gestion des erreurs, c'est bien plus avance que tout ce qui est implemente dans les DE actuel.
Bon, c'est pas non plus completement tout rose bonbon. KDE et Enlightenment ont tous les deux une infrastructure qui permet de precharger/prelinker/preinitialiser leur bibliotheque interne avant de demarrer une application. Hors cela repose sur fork, sans exec. Et c'est pour l'instant pas possible a implementer dans systemd, donc on perd une optimisation (Amelioration du temps de demarrage et diminution du la memoire utilise). De plus comme GNOME n'a pas ce mecanisme, et que les communautes de KDE et E ne sont pas tres engage dans le developpement de systemd, et bien je doute que l'on verra une solution a ce probleme apparaitre.
[^] # Re: Mon avis personnel
Posté par needs . Évalué à -5.
Mon dieu… Je laisse tomber, visiblement le gout des belles choses se perd…
[^] # Re: Mon avis personnel
Posté par xcomcmdr . Évalué à 2.
Le goût pour l'attaque personnelle monte en flèche, par contre.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon avis personnel
Posté par needs . Évalué à 2.
Rien de personnel la dedans, c'est un constat global. Si tu le prends comme une attaque personnel, je m'en excuse, ce n'était pas l'intention.
[^] # Re: Mon avis personnel
Posté par Frank-N-Furter . Évalué à 3.
Les scripts shell de belles choses? Faut arrêter le crack.
Depending on the time of day, the French go either way.
[^] # Re: Mon avis personnel
Posté par ariasuni . Évalué à 2.
Pour le moment, un développeur de KDE a dit qu’il préférait maintenir un seul truc que session systemd + autre chose pour les autres. Même si ça change dans le futur, je pense qu’il y aura toujours quelque chose pour ceux qui n’utilisent pas systemd.
Écrit en Bépo selon l’orthographe de 1990
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 12 février 2014 à 13:09.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mon avis personnel
Posté par cosmocat . Évalué à 3.
Complément:
C'est assez marrant ce pattern "D U O V F" chez ceux qui ont voté systemd alors que pour les autres le 'F' est très présent. Peut-on en conclure quelque chose…
Si y'en a qui ont bien suivi les débats, je suis intéressés. A vos claviers! ;)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mon avis personnel
Posté par Spyhawk . Évalué à 6.
Voter 'F' (Further discussion) est un moyen de contourner l'avantage du double vote du président de comité en cas d'égalité, qui ne s'applique pas contre l'option par défaut (F, justement).
C'est un simple blocage de la part des pro-upstart (voir le journal Debian-systemd précédent, lien dans mon commentaire plus bas).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mon avis personnel
Posté par Spyhawk . Évalué à 4. Dernière modification le 12 février 2014 à 14:33.
Non, il suffit seulement de voter F avant D (on est dans un système de Condorcet). C'est exactement ce qui s'est passé lors du premier vote (4-4, mais F globalement avant/équivalent à D, donc le vote supplémentaire de Bdale ne servait à rien).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 12 février 2014 à 14:46.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mon avis personnel
Posté par Spyhawk . Évalué à 6. Dernière modification le 12 février 2014 à 14:54.
Tous les membres du comité se fichent d'OpenRC (pour le noyau Linux).
C'est clairement faux. Après 5 (cinq!) mois de discussion, pour l'init par défaut, et uniquement pour le noyeau Linux, y'en a quelques un qui ont estimé qu'avoir une décision (même le status quo) est plus important que de discuter encore 5 mois supplémentaires. Y'a qu'à voir la menace en privé d'une GR si la décision ne tombait pas "dans un très court délai".
C'est d'ailleurs pour ca que Colin Watson (employé Canonical) a voté "U D .. F ..", en sachant que ca donnerait systemd gagnant. Systemd n'a pas sa préférence, mais le cirque a assez duré et il est temps de se poser les autres questions importantes.
[^] # Re: Mon avis personnel
Posté par Diagonale de Cantor (site web personnel) . Évalué à 3.
Non pas du tout
si on avait comme vote
4 x (D U O F V)
4 x (O U F V D)
On remarque en faisant des comparaison deux à deux que
on a 4 fois D>U et 4 fois U>D (D=U)
on a 4 fois D>F et 4 fois F>D (D=F)
on a 4 fois D>O et 4 fois O>D (D=O)
on a 4 fois U>O et 4 fois O>U (U=O)
Par contre on a clairement O>F et U>F
Donc D U et O ne sont battue par personne mais F est battue par O et U.
Donc deux solutions :
– soit on supprime F et dans ce cas pour trancher le chairman peut choisir D.
– soit on garde F et dans ce cas là un nouveau vote doit avoir lieu et le fait d’avoir placé O en tête ne change rien.
[^] # Re: Mon avis personnel
Posté par Diagonale de Cantor (site web personnel) . Évalué à 3. Dernière modification le 12 février 2014 à 15:16.
Pour plus de précision, vue qu’ils utilisent (1) l’ensemble de Shwartz pour trancher (l’ensemble des imbattus), c’est à dire dans le scénario où O est en tête l’ensemble {U D O} qui ne contient pas F. Donc, en fait, mettre O en têtes fait gagner D.
C’est beau Condorcet, c’est intuitif :)
(1) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729
[^] # Re: Mon avis personnel
Posté par arnaudus . Évalué à 8.
Un beau vote de geeks :-) Avec le vote uninominal, on ne vote pas pour le candidat qu'on veut, mais la stratégie est accessible aux QI d'huitres. Avec Condorcet, on ne vote pas non plus pour ce qu'on voudrait, mais il faut passer 15 jours à déterminer la stratégie optimale.
[^] # Re: Mon avis personnel
Posté par mickabouille . Évalué à 5.
Une des propriétés considérée en théorie des votes, si je me souviens bien, est l'honnêteté des votes, c'est à dire que l'on vote réellement pour ce qui nous semble le mieux et pas de façon stratégique. justement, le fait de ne pas pouvoir simplement trouver une stratégie optimale apparaît comme une bonne propriété :)
Accessoirement, le fait que les résultats des sondages ne sont pas publiés dans les derniers moments d'une élection en France semble cohérent avec cet objectif.
[^] # Re: Mon avis personnel
Posté par arnaudus . Évalué à 4.
Bah je ne suis pas vraiment d'accord : une bonne propriété d'un système de vote est quand la stratégie optimale est le vote honnête. S'il existe une stratégie optimale complexe, c'est qu'il y a un problème; d'une part, le système de vote est illisible, ce qui pose quand même un problème en démocratie et autorise toutes sortes de manipulations difficiles à contrôler (du type redécoupage de circonscriptions par une armée de polytechniciens); d'autre part, tu permettrais à une minorité (qui a les moyens matériels et intellectuels de déchiffrer les tenants et les aboutissants du système de vote) de peser déraisonnablement sur le résultat du vote. Accessoirement, s'il existe de telles stratégies hyper-complexes, tu as de fortes chances pour que la plupart des votants votent justement n'importe quoi (ni honnête ni optimal) parce qu'ils ont suivi les conseils d'un hoax reçu par email.
# Le journal...
Posté par Spyhawk . Évalué à 4. Dernière modification le 12 février 2014 à 12:36.
Le journal précédent sur Debian et systemd est celui-ci.
Mais sinon, effectivement le vote n'a défini que l'init par défaut pour le noyau Linux (après 5 mois de discussion), donc on a encore de beaux trolls devant nous.
[^] # Re: Le journal...
Posté par Maxime (site web personnel) . Évalué à 3.
Le journal que tu cites a été publié avant la fin des votes. Même si l'issue était connue, on était pas à l'abri d'un changement au dernier moment…
Maintenant c'est officiel.
# logs au format binaire
Posté par savitzkaia . Évalué à 10.
Pour ma petite expérience personnelle, le framework que j'utilise tous les jours au boulot utilise un format binaire pour ses logs et j'avoue que, si ça m'a surpris au début, cela s'est avéré être :
Donc bien que réticent au début, je suis maintenant pour le concept et couine un peu quand je dois travailler sur des logs java avec leurs lignes de 3km de long…
[^] # Re: logs au format binaire
Posté par goeb . Évalué à 3.
Les 3 arguments que tu donnes sont aussi vrais pour des logs texte.
Avec des logs texte, on peut utiliser 'grep' avec des options, ou tout autre outil mieux adapté.
Les logs texte ne sont pas obligés de répéter la date à chaque fois. Mais je t'accorde que c'est souvent répété afin de pouvoir 'greper' facilement.
Pareil pour les logs texte.
Si tes logs en binaire contiennent 3km de ligne, tu auras le même problème.
[^] # Re: logs au format binaire
Posté par barmic . Évalué à 10.
Avoir toutes les infos entre le 31 décembre 2013 17h et le 1er janvier 7h ? Ça demande une jolie expression régulière et à connaître le format exacte des dates du log en question ainsi que sa position (note que ce sera probablement plus pratique en awk ou en perl).
Il n'y a pas que la date. Aujourd'hui un log c'est un ensemble d'informations contextuelles (le niveau, la date, le pid, l'utilisateur de l'application, etc) suivi d'un message.
Il rappel que l'on ne perd pas cette fonctionnalité. Tu peux donc toujours régénérer un format texte et utiliser tes outils habituels.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: logs au format binaire
Posté par savitzkaia . Évalué à 2.
merci, j'aurais pas dit mieux.
[^] # Re: logs au format binaire
Posté par gnumdk (site web personnel) . Évalué à 10.
Alors toi, tu n'as jamais du faire des recherches dans des vrais logs dans la vraie vie… Sur un serveur qui se respecte, sur de la grosse quantité de log, tu te retrouves vite à devoir aller boire douze café entre le moment ou tu lances tes grep, awk & co et le moment ou tu vois le résultat voulu…
L'avantage de journalctl, c'est justement de n'utiliser ces outils qu'une fois les filtres de base appliqués et donc sur des quantités de données minimales…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: logs au format binaire
Posté par savitzkaia . Évalué à 3.
non mon employeur ne serait pas content mais globalement si tu prends le concept de log4j tu as en début de ligne par défaut:
ce à quoi tu vas ajouter des informations de contexte diverses et variées comme le nom de machine, le numéro de transaction, peut-être le numéro de thread, le pid du process, le mode ou que sais-je pour connaître le contexte de l'événement loggé, et ceci à CHAQUE ligne, ce qui te bouffe les 3/4 de ta console (j'exagère un peu là, j'ai un grand écran mais c'est pour l'effet dramatique) pour un bout d'information que tu cherches.
Pour peu que tu aies un grand nombre de transactions par secondes ça devient très vite compliqué de parser le tout, les logs étant verbeux les rotations se font trop vite pour que tu aies le temps de voir ton message passer, et tu te rends compte en faisant un calcul simple (on l'a fait) que l'impact sur les performances est loin d'être négligeable (écriture disque).
J'apprécie beaucoup le fait d'avoir des logs de textes de temps en temps mais j'avoue, lorsque l'application bourre ça devient vite compliqué.
[^] # Re: logs au format binaire
Posté par fredoche . Évalué à 3.
Après c'est peut être l'opportunité de simplifier l'appender log4j et de laisser au journal/syslog une partie du travail de strucutre et de contextualisation (date, PID…)
[^] # Re: logs au format binaire
Posté par savitzkaia . Évalué à 1.
c'est pas faux ;-) Après utiliser syslog/rsyslog/syslog-ng/… demande de faire intervenir les admin sys et de procédurer la chose, ce qui n'est pas toujours simple, les environnements évoluant en fonction des contraintes qui leur sont imposées.
# Ouf : par défaut
Posté par bghflt (site web personnel) . Évalué à -6.
Le board Debian a surement ses bonnes raisons.
[MA VIE]
Est-ce que les gens comme moi, avec presque 25 ans de culture Unix (dont 18 de Linux) vont se jeter sur cette nouveauté, pas sûr.
Autant le bachotage de grosses évolutions comme IPTABLES ou grub se justifiait à coup de nuits blanches, autant cette grappe de trucs ne sert à rien sur des configs modestes ou domestiques et en prime la palanquée de réflexes et scripts maison à adapter.
Je vais attendre que Ken Thompson ou Brian Kernighan donnent leur avis.
Rien qu'en pensant à certains plugin Munin, j'ai mal au crane.
[^] # Re: Ouf : par défaut
Posté par gnumdk (site web personnel) . Évalué à 8.
Tu bientôt pouvoir recommencer ;)
[^] # Re: Ouf : par défaut
Posté par Maclag . Évalué à 7.
domestique:
Sérieux t'as une palanquée de scripts maison que tu maintiens sur tes ordis domestiques? Moi non, par contre en domestique je prends systemd rien que pour le temps de démarrage plus rapide, vu que le reste ne m'impactera probablement pas du tout directement.
modeste:
Pareil, j'ai du mal à imaginer que sur un petit parc la migration soit extraordinairement compliquée.
D'un autre côté, je comprends très bien aussi le principe de ne pas toucher à quelque chose qui fonctionne bien, et ça m'aurait surpris de voir une épuration de tout autre système d'init déjà présent.
Par contre, autant te faire à l'idée: il faudra bien que tu y passes!
# Perso...
Posté par pasBill pasGates . Évalué à 10.
Je suis bien content de voir que la communaute Linux se rapproche de plus en plus de Windows avec systemd, journald, etc…
Ca a mis du temps, mais j'ai confiance. Bientot il y aura une base de registre pour tout le systeme plutot que ce merdier de /etc , installer un programme ne forcera plus a upgrader toutes les dependences, et qui sait, peut-etre meme un demineur !
Sur ce, je -->[]
[^] # Re: Perso...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Diantre, le retour de pBpG, et quel retour ! Chapeau bas, c'était très bien exécuté !
[^] # Re: Perso...
Posté par ne . Évalué à 5.
Son commentaire est surtout très vrai. Il faudrait ignorer le fonctionnement de la gestion des services windows et les journaux d'évènements pour dire le contraire.
[^] # Re: Perso...
Posté par cedric . Évalué à 4.
Il n'y a pas deja une base de registre dans GNOME ? Et avec mono, je pense qu'on a tout ce qu'il faut pour concurrencer Windows maintenant. Tu vois d'autre truc qui manque apres ca qu'on s'y attaque !
[^] # Re: Perso...
Posté par pasBill pasGates . Évalué à 3.
Oui mais c'est uniquement pour Gnome, faut mettre ca pour le systeme entier histoire d'avoir une unification du stockage de parametres plutot que 523 formats de configuration differents.
Sinon, si vous pouviez mettre une platforme de filtrage reseau similaire a WFP dans le kernel ca serait sympa, ca me fait pas mal ch… en ce moment de ne pas pouvoir intercepter et modifier facilement tout le traffic que je veux. netfilter est sacrement limite de ce cote la.
[^] # Re: Perso...
Posté par cedric . Évalué à 3.
Meme en utilisant LibreOffice ? Je croyais que c'etait ce qui se faisait de mieux sous Linux pour le Firewall…
Pour le probleme de la base de registre, il y a deux options, GNOME OS ou convaincre chaque projet de migrer vers une base de registre. Une recommendation ? Me semble que tout faire facon GNOME est une meilleur strategie, suffit d'enlever des options et mettre une base de registre.
[^] # Re: Perso...
Posté par xcomcmdr . Évalué à 6.
LOL, comme si les clés dans le Registre Windows étaient documentées et répondaient à une quelconque logique.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Perso...
Posté par pasBill pasGates . Évalué à -1.
Tu veux comparer ca a ce qu'on trouve sous /etc pour rire ?
[^] # Re: Perso...
Posté par xcomcmdr . Évalué à 1. Dernière modification le 13 février 2014 à 20:44.
Si tu veux.
Voir si le TRIM est activé sur mon SSD :
Consulter la présence du mot clé discard pour le point de montage / dans /etc/ftab
Sous Windows, c'est hyper intuitif :
Ou pour mettre l'UTC sous Windows, c'est encore très intuitif :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] “RealTimeIsUniversal”=dword:00000001
C'est caché au fin fond du registre. Génial. Mais la devinette, c'est marrant 5 minutes. Heureusement, pour pas mal de cas, il y a Google (et on ne trouve pas ça sur une quelconque doc' MS).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Perso...
Posté par pasBill pasGates . Évalué à -3.
Super, quelle difference entre les 2 ?
Cache ? Au fin fond ? Non, c'est la ou c'est sense etre dans la hierarchie.
Je peux faire REG ADD HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /f /v RealTimeIsUniversal /t REG_DWORD /d 1 depuis la ligne de commande pour le modifier ou le lire.
Tu m'expliques comment tu modifies un parametre en ligne de commande dans un fichier de configuration arbitraire sous Linux ?
[^] # Re: Perso...
Posté par claudex . Évalué à 7.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Perso...
Posté par xcomcmdr . Évalué à 1.
'discard' fait référence à la manière dont TRIM fonctionne. On s'en souvient rapidement ainsi.
Non seulement DisableDeleteNotify je vois pas le rapport, mais en plus fsutil behavior query, faut que je regarde sur le Web à chaque fois pour m'en souvenir… Je m'attendrais plus à des arguments du genre /B /Q, mais non…
Moi aussi je peux faire une hiérarchie non documenté, avec des noms abscons (SYSTEM\CurrentControlSet\Control, juste WUT ? "RealTimeIsUniversal", c'est un fan de SF qui a inventé ce nom pour l'UTC ?), et dire que c'est bien rangé.
Ça restera bordélique.
sed, vim, vi, nano, echo. Y'a l'embarras du choix.
Dans le cas de fstab, tu peux même remonter un point de montage avec des options différentes.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Perso...
Posté par pasBill pasGates . Évalué à 6.
La tu me fais quand meme bien rire. SYSTEM c'est clair, "CurrentControlSet" c'est decrit ici : http://support.microsoft.com/kb/100010 et ca a tout a fait un sens. Mais evidemment si tu n'as meme pas pris la peine d'essayer…
Rappelles moi, /etc c'est quoi ? rc.d ? Super clair pour celui qui connait pas… Tu t'y es habitue pourtant.
Ca c'est pas une reponse. Tu veux changer un parametre dans fstab, ou dans krb5.conf, ou dans network, … avec un truc automatise (script ou autre) tu dois a chaque fois faire une tambouille differente et te faire le parsing du fichier a la main pour trouver ta valeur parce qu'ils ont un format different.
Avec la registry, tu utilises le chemin de la valeur et c'est tout, changer la valeur c'est bateau, et si tu fais une erreur et essaie de mettre un bout de texte dans une valeur numerique, tu recois une erreur plutot qu'un truc qui te laissera faire car il n'a aucun contexte sur le type des valeurs.
La je n'ai meme pas encore touche :
- le fait que chaque cle peut avoir ses propres attributs de securite, ce qui permet une granularite pour donner des permissions de configuration qui est impossible avec les fichiers de config texte.
- que tu peux avoir un audit des modifs de la registry par cle plutot qu'un fichier entier
- ca te permet de faire un push de parametres de config specifiques sur toutes les machines d'un domaine, bonne chance pour faire ca quand tu dois modifier une valeur precise dans un fichier de config qui est peut-etre different sur 3000 machines
- le fait que la registry te permet de creer des transactions, changer plusieurs clefs a droite a gauche, et si qqe chose merde, tu peux faire un rollback. Amuses toi a faire une transaction solide avec plusieurs fichiers de config…
[^] # Re: Perso...
Posté par ariasuni . Évalué à 4. Dernière modification le 16 février 2014 à 00:43.
J’aimerais quand même dire une chose: il faut admettre que n’importe quel programme sous Windows laisse plein de merdes dans le registre. CCleaner en enlève tellement à chaque fois que je le fais tourner, c’est assez impressionnant.
Sinon oui ça peut être pratique un registre, mais il faut également admettre que les noms font assez peur.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Perso...
Posté par groumly . Évalué à 4.
La difference entre les deux c'est que la base de registre peut être très aisément consulter par un programme de façon fiable. Pour les humains, on a invente les front ends. Ca marche vachement mieux que d'aller trifouiller au fond du système. Et ces front ends ont besoin d'un api fiable. 42 000 formats texte, c'est pas une api fiable.
Verifier la presence de discard dans une ligne, ca veut dire parser tout le fstab et l'analyser.
Alors, oui, tu peux faire un awk + grep. Et un jour, y'a un gars qui va mettre un commentaire #surtout ne pas activer discard!!! et paf, tu vas croire que TRIM est active. Le fix est facile, mais le mal sera deja fait.
Idem pour l'exemple UTC, c'est très logique et y'a pas d'ambiguïté sur la sémantique.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Perso...
Posté par claudex . Évalué à 4.
Ça permet quoi de plus ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Perso...
Posté par pasBill pasGates . Évalué à 3.
cf. http://msdn.microsoft.com/en-us/library/windows/desktop/aa366492%28v=vs.85%29.aspx
Ca te permet d'intercepter/modifier facilement le traffic a tout un tas de niveaux differents allant d'Ethernet a RPC en passant par IPSEC, etc…
Netfilter par contre ne te permet de faire ca qu'au niveau IP.
[^] # Re: Perso...
Posté par fravashyo (site web personnel) . Évalué à 6.
il y a quand même plus de fonctionnalités dans windows que dans Gnome. De plus les dev Windows sont plus à l'écoute et moins condescendants envers leurs utilisateurs.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Perso...
Posté par cosmocat . Évalué à 5.
Je trouve ça fort de dire çà quand on sait le succès rencontré par l'interface ModernUI de Windows8 et le pataquès que les utilisateurs ont été obligé de faire pour qu'il y ait le retour du bouton démarré. Et Microsoft a réussi à pas les écouter (ce n'est pas le bouton démarré qui est revenu) et à fait juste un bouton qui ouvre l'interface d'accueil que les utilisateurs du mode bureau voulait justement fuir…
[^] # Re: Perso...
Posté par Strash . Évalué à 6.
Demander aux utilisateurs n'est pas toujours la bonne solution, voire même jamais. L'utilisateur a la plupart du temps des œillères si grandes qu'il ne propose rien d'intéressant. L'innovation, la vraie, viens souvent d'une rupture avec un paradigme précédent. Je ne dis pas que l'interface de Windows 8 est bonne ou mauvaise, mais je dois concéder à Microsoft qu'essayer d'introduire une vraie rupture par rapport à l'ancien (qui date quand même de Win 95) est une bonne chose. Le "If it ain't broke, don't fix it" est pour moi synonyme de stagnation.
Les interfaces utilisateurs ne sont pas une science exacte, surtout qu'il y a toujours une armée de réfractaires aux changements pour gueuler contre elle. Cette levée de boucliers contre systemd, Wayland, et autre est vraiment une preuve que même dans un domaine évoluant à une vitesse folle, les réfractaires aux changements sont légion. Certains messages me font penser aux réactions face à l'invention de l'imprimerie…
[^] # Re: Perso...
Posté par reno . Évalué à 7.
Bah, qu'il y ait une mode des interfaces utilisateurs et que donc le changement pour le changement soit un plus, hum, comment-dire, c'est la victoire du marketing sur la "vraie" simplicité d'utilisation.
Tu ne doit pas aimer la ligne de commande, ça ne change pas assez..
Tiens, je te conseille de lire ça des nouveautés:
http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/
j'aime bien son point de vue.
PS: Je ne dis pas que ça s'applique à Wayland (ne serait-ce qu'à cause des failles de sécurité inacceptable d'X), par contre systemd, j'ai l'impression que la compatibilité avec SysVinit est loin d'être parfaite (d'après une page de LWN, désolé elle est encore 'réservée aux contributeurs') et que le coté journalisation est encore immature..
[^] # Re: Perso...
Posté par SwordArMor (site web personnel) . Évalué à -3.
Tout dépend de comment on voit les choses. Pour ma part je préfère avoir quelque chose de vieux et éprouvé (une peu comme ce que faisait Debian jusqu’à présent), quelque chose qui juste marche en somme, que quelque chose de « innovant » qui vient foutre la grouille partout et qui en plus est mal conçu (ça reste du Poettering, et tout le monde connais pulseaudio).
D’ailleurs, pourquoi remplacer un système fonctionnel par une infamie ? Si c’est pour les 10% d’adminsys qui ont quelques gigas de logs à traiter par jour, ça ne suffit pas.
[^] # Re: Perso...
Posté par gnumdk (site web personnel) . Évalué à 3.
Le problème de Windows, ce n'est pas le gestionnaire d'événements, ce sont ces derniers: me dire que tel truc n'a pu démarrer sans autre information, ça ne sert à rien…
[^] # Re: Perso...
Posté par pasBill pasGates . Évalué à -1.
Les services ont un log a eux d'habitude, comme sous Unix.
[^] # Re: Perso...
Posté par Maclag . Évalué à 9.
Tant qu'ils n'implémentent pas l'écran bleu…
Sérieusement, ce n'est pas parce que Windows fait un truc que c'est forcément de la merde et qu'il ne faut pas faire quoi que ce soit de similaire.
Maintenant, on peut regarder ce qui se fait sous Windows et conclure:
"Il y a du bon dans ce merdier, il suffit de faire pareil, mais en bien."
Et voilà, systemd!
Ce Troll vous est offert par la Ligue pour la Lourdeur, l'Offense, le Remue-ménage et les Trolls: la llorT
# pkoi?
Posté par Stibb . Évalué à 1.
ou est ce que l on peut trouver un resumer des raisons technique de ce choix?
[^] # Re: pkoi?
Posté par Prosper . Évalué à 5.
https://wiki.debian.org/Debate/initsystem/systemd
[^] # Re: pkoi?
Posté par Stibb . Évalué à 1.
merci pour le lien! Recommende de mettre dans le journal et et promouvoir en depeche.
# Ubuntu passe à Systemd
Posté par Frédéric Massot (site web personnel) . Évalué à 7.
Mark Shuttleworth vient d'annoncer que Ubuntu passera à Systemd
[^] # Re: Ubuntu passe à Systemd
Posté par Albert_ . Évalué à 9.
Merde mais c'est pas possible il ne peut pas faire ca. Et comment on va troller comme des gorets en crachant sur Ubuntu qui fait tout dans son coin?
[^] # Re: Ubuntu passe à Systemd
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 14 février 2014 à 16:55.
Les anti-systemd vont encore plus hurler :).
Et comme parmi eux, aucun ne se bottera le cul pour maintenir "les truc qui marchaient bien" mais qui étonnamment ne marcheront plus sans mainteneurs, et ce pour la simple raison que systemd ne changera pas grand chose pour eux, qu'il feront de l'admin comme avant, sans même possibilité de dire "upstart rulez, c'était le choix à faire pour les autres", et qu'ils l'utiliseront comme tout le monde, on va avoir le droit à quelques râlements pendant quelques années (et ensuite, ils éviteront soigneusement de rappeler qu'ils étaient contre, dans 10 ans on ne trouvera personne qui dira publiquement qu'il était contre) :-D.
En tous cas, c'est bien fairplay de la part de Canonical, surtout avec une telle rapidité pour enfin passer à autre chose (pour les acteurs, pour les trolleurs on s'en fout)…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.