Das gute alte
big design up front.
Ich bin mehr der Freund von
little design up front.
Man muss sich auch die Frage stellen was man designed. Interfaces oder Implementierungen. Ich glaube auch, dass fettes Design in Richtung Over-Engineering geht.
Allerdings habe ich da nicht wirklich eine starke Meinung dazu, weil ich habe beide Ansätze schon grandios funktionieren und katastrophal scheitern gesehen, sowohl beides als Extrem, als auch Abstufungen davon. Ich glaube, was gut läuft in dem Zusammenhang hängt stark von den jeweiligen Entwicklern und Projekten ab.
In dem Fall stimme ich aber zu, dass es schön gewesen wäre wenn man die Implikationen von -o json als Array im Zusammenhang mit dem -f Switch schon in früheren Versionen durchdacht hätte. So komplex ist die Überlegung nicht.
So wie ein Programm, das JSON-Output verarbeitet, schon in der ersten Version mit Multi-Line-Output umgehen können sollte.
Ich glaube du hast das Problem nicht ganz verstanden.
Die neue (bisher von dem Skript unterstützte) Version von Systemd schreibt vor, dass "-o json" JSON ist, das per Zeile ein JSON-Objekt ausgeben wird. Anders gesagt ist das Protokoll newline-delmited JSON-Objects. Mehr als eine Zeile JSON-Objects ist kein valides JSON, genauso wie zwei Objekte kein Valides JSON ist, drum braucht man wie in jedem Protokoll einen delmiter.
Wollte das Skript auf der von Debian abgeleiteten Distribution für Beaglebone laufend machen. Dort ist aber das Problem mit -n0, -n1-Problem (nicht dokumentiert). Außerdem eben das -f-Problem, dass es scheinbar in diesem Fall niemals valides JSON ausgeben wird (weil es ein Array ist, das niemals terminiert). Alles mit Workarounds zu unterstützen, aber im Verhältnis ziemlich unnötig komplex, wenn man einfach zu den Zehn (ja, genau zehn derzeit) möglichen Outputs, die (hoffentlich) recht unabhängig von der Implementierung sein sollten den einen alten JSON-Output gleich halten hätte können. Relativ simples Interface-Design, also nichts wo man sich großartig was durchdenken muss.
Kurzum hätte multiline-JSON-Support nichts geholfen. Das Programm wäre so schlicht nie korrekt gelaufen, weil das nie gefragt oder von journalctl gewünscht war. Sollte so etwas kommen ist es ein Protokoll-Bruch und sollte wenn, dann so behandelt werden. Wie gesagt, war aber nie der Fall, sondern einfach, das die Ausgabe nicht kompatibel ist ohne, dass sich der Name des Formates geändert hat.
Es ist halt immer die Frage, ab wann man Altlasten rausschmeißt. Wenn man nicht aufpasst, schleppt man eines Tages so viele kleine Altlasten mit sich rum, dass man praktisch nur noch mit Wartung beschäftigt ist - X11 lässt grüßen.
Es macht aber einen Unterschied, ob man Dinge, die nicht mehr gebracht werden weg tut oder ob man für jede Version von Linux ein eigenes Interface unterstützen muss, weil unterschiedliche Versionen sind. Es geht hier um Darstellung von Logs, nicht großes.
Im Extremfall landet man bei Zuständen wie auf dem Mainframe, der bei Textdateien mit mehr als 72 Zeichen pro Zeile hart abbricht. Völlig logisch: Lochkarten haben 72 Spalten und wenn Input mit mehr als 72 Spalten vorliegt, muss beim Einlesen ein Fehler aufgetreten sein. Die Abwärtskompatibilität muss gewahrt bleiben...
Ist aber schon sehr weit hergeholt. In dem Fall sind keine Limitierungen weggefallen und es ist auch nicht "früher mal" eine sinnvolle Entscheidung gewesen. Auch wurde die Kompatibilität nicht gebrochen worden, weil sich die Umstände geändert haben. Außerdem bricht mein Programm nicht mit neuen Versionen, sondern hat einfach keinen Support für eine Alte.
Es geht eher darum, dass man wenn man Interfaces macht, dass man sie nicht einfach komplett verwirft. Das ist ja quasi der Sinn von Interfaces. Die Sache ist, dass da der Hintergrund ja nicht einmal Altlasten sind. Wenn -n0 was anderes macht, als dokumentiert, dann ist es ein Bug. Wenn man sich zwischen einem Array von Objekten und einem Objekt pro Zeile entscheidet ist das ja auch nicht wirklich Altlast, sondern unterschiedlicher Output. Die Kosten von der "Altlast" (ist ja nicht wirklich eine Altlast indem Sinne, dass man es nicht mehr braucht oder so) sind ein paar Zeilen Code. Hast du dir journalctl mal angesehen? Die haben da drin drei JSON-Ausgabearten_ Server Sent Events Style (mit data: vor jedem JSON), JSON (one per Line steht da explizit) und JSON-Pretty, aber keine davon ist kompatibel mit anderen Versionen.
Und weil ich glaube, du hast mich missverstanden. Ich patche den Support drauf für ältere Versionen, die eben dieses andere Format hatten, weil es die offensichtlich mal bei früheren systemd-Versionen gab (changelog von Systemd sagt nicht wann das umgestellt wurde).
Insofern ist es einfach so, dass die ersten Versionen, wohl einfach nicht sonderlich durchdacht und ziemlich buggy waren, was entweder auf die Entwickler oder auf die Komplexität zu schieben ist. Dass valides JSON mit -f-Switch und ein -n0 unmöglich sind in der alten Version ist bei einem Tool, das sonst nicht viel mehr macht finde ich ziemlich schlimm. Wie gesagt, in der neueren Version läuft's prima, nur scheinen diverse Distros auf Debian und RedHat-Basis noch herumzukursieren.
EDIT: Ich kann auch noch ein Beispiel geben, wo sie es richtig gemacht haben. Die alte Version hatte keinen -u-Switch (für Unit File), man kann aber in beiden Versionen einfach danach filtern.
Wie gesagt, habe nichts gegen neu machen, auch mal Kompatibilität brechen, damit was weitergeht, genauso wie ich nichts gegen Rewrites und dergleichen habe, nur wenn ich zwei Versionen von einer (quasi) API habe und mein Backend beide ohne großen Aufwand beibehalten kann, dann wäre das nett und ja, das ist eine Sache die nicht groß ist und die solang irgendeine Art von JSON-Ausgabe unterstützt wird keine Altlast, die man groß maintainen muss für ein paar Wenige. Den Code kann man auch mal wegtun, wenn die alte Version nicht mehr groß unterstützt wird. Das geht doch in anderen Tools auch ganz gut.
EDIT2: Sorry, wollte den Thread nicht groß auf den Post lenken, sondern eher, da es Sysadmins hier gibt, die mit Linux zu tun haben ein Heads-Up: Verlasst euch nicht drauf, dass journalctl immer und überall gleich funktioniert, auch wenn es zunächst mal so aussieht. Habe ja danach gesucht und in der Changelog, Doku oder so steht nichts davon.
EDIT3: Es gibt auch ein
export format, das unter einer
stability promise ist, das aber ebenfalls Unterschiede zwischen den Versionen aufweist, was scheinbar auch unter den Tisch gekehrt wurde. Die
Stability Promise sagt, "starting with version 26", die getestete alte Version ist 44. Die Änderung in dem Fall ist dass der Satz "Entry metadata that is not actually a field is serialized like it was a field, but beginning with two underscores." falsch ist. Zumindest in Version 44 gibt es keine two underscores, sondern einen Punkt. Damit bricht das die Stability Promise, ohne dass das dort dokumentiert wäre.
EDIT4: Noch ein paar nette Findings: "systemd-journalctl -f" flushed wenn es Lust hat. Es gibt also keine Events und ein "systemd-journalctl -f > journal.log" wird journal.log nicht aktuell sein, wenn nicht genug Daten geschrieben werden. Es gibt keinen Weg das zu ändern. Egal welches Format man als Ausgabe nimmt, es gibt eine Output-Zeile am Anfang, die man nur abdrehen kann wenn man -q anschaltet, was nicht dokumentiert ist (-q soll laut Doku Permission-Warnings abdrehen). Letzteres ist einigermaßen okay, sollte aber dokumentiert sein, nur ein Logging wo ich nicht ohne weiters an aktuelle Logs rankomme ist ziemlich undurchdacht. Erstes scheint aber in der aktuellen Version gefixed. Das -q-Problem besteht immer noch. Man kann auch nicht zwischen warnings und infos unterscheiden. Wäre alles halb so wild, wenn es einen besseren Weg gäbe da drauf zuzugreifen. Wäre aber cool so einen Hacker-Film zu haben und statt dem ganzen "Der Anruf darf nicht so lang sein, sonst traced er dich" ein "Die Systemd-Messages dürfen nicht zu lang sein, sonst bekommen sie es mit". Notiz am Rande: Die besseren Versionen sind die wo es keine AUTHOR section mit Poettering mehr gibt.
