Boycott Systemd

Status
Für weitere Antworten geschlossen.
rubricanis schrieb:
... Wirkliche Inovationen gibt es wohl eher im embeddet Bereich, ...
Zum Vergrößern anklicken....

*rofl*... Bspw. Busybox?!?? Ein monolithischer Block, bei dem meiner Meinung nach
die einzige als standalone verwendbare Komponente runit (obwohl ich diese als sehr
schoen und sehr gut durchdacht empfinde) darstellt (von im Eingebetteten Systemen
mit OS am meisten, aus Kostengruenden, gebraeuchlichen "Kernel" oder "Patchsets"
will ich nicht mal anfangen in meinen kuehnsten Alptraeumen zu denken).

Oder Android als Projektionsflaeche von Anwendungen bei eingebetteten Systemen,
bspw. Car Entertainment Systems???

Ooooeh.... Innovationen?!?? Beispiele? :)

Es sei angemerkt, dass meiner Meinung nach das Inferno OS eine echte Innovation
darstellt bzgl. dem Darstellen von Eingebetteten Systemen.
 
Busybox stellt einen Userspace, bzw. ist meiner Meinung nach
ein "Antipattern", was bspw. in Kombination mit Linux und uLibc
verwendet wird, Betriebssysteme fuer Eingebettete Systeme
darzustellen.

-> ${OS} = Linux + uLibc + Busybox

Das was ich meiner Meinung nach bspw. als kritisch bewerte, ist
die Tatsache, dass derartige Betriebssysteme, ein Sammelsurium
von 3rd-Party Softwarekomponenten sind.

seL4 ist *imho* alter Wein in neuen Schlaeuchen , das sieht
sehr nach 3rd-Party-Mix aus... aber, bevor ich mich zuweit aus
dem Fenster lehne, sollte trotzdem mir mal die Codebasis von
seL4 ueberfliegen, denn ein Blick ueber den eigenen Tellerand
kann nicht schaden.

Denn ich sollte selbst nicht den Fehler begehen, zu versuchen,
als Blinder ueber Farben zu urteilen. :D

Meiner (aeusserst subjektiven) Meinung nach, ist nahezu alles
was Linux-basiert ist (oder von dem Linux-kernel deriviert ist)
und dann oftmals (erschreckenderweise) noch in Kombination
mit C++ basierten Softwarekomponenten ein absolutes NOGO
fuer das Darstellen Eingebetteter Systeme (oder Dergleichen).

Letztendlich, wuerde ich meiner Meinung nach fuer den Einsatz
in Eingebetteten Systemen entweder bspw. RTMX oder QNX als
OS empfehlen. Aber, alles was seinen Ursprung im Linux-kernel
hat meiden (wie der Teufel das Weihwasser), da Codebasis ist
meiner Meinung nach *pain-in-the-ass* bzgl. Analyse interner
Struktur und bzw. dann mit dieser dann versuchen produktiv zu
arbeiten, um ein spezifisches (technisches) Problem zu loesen.

rubricanis schrieb:
Irgendwann werde ich mir auch Inferno mal anschauen...
Zum Vergrößern anklicken....

-> http://www.vitanuova.com/inferno/docs.html

Es lohnt sich. :)
 
Dass NetBSD signifikant töter ist als noch vor einigen Jahren, bezweifle ich. Die haben doch mit EdgeBSD jetzt eine treibende Forkkraft ... :D

Ernsthaft: NetBSD habe ich in letzter Zeit deutlich häufiger gesehen als DragonFly BSD. Letzteres scheitert m.E. vor allem daran, dass es kaum Werbung bekommt. Bislang noch jeder, dem ich das aus irgendeinem Grund gezeigt habe, fand es schade, davon nie zuvor gehört zu haben. Dabei haben die eigentlich eine Menge, womit sie angeben könnten.
 
CrimsonKing schrieb:
Dass NetBSD signifikant töter ist als noch vor einigen Jahren, bezweifle ich. Die haben doch mit EdgeBSD jetzt eine treibende Forkkraft ... :D
Zum Vergrößern anklicken....

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
http://www.slideshare.net/eurobsdcon/andy-tanenbaum-euro-bsdcon2014v2

AST wuerde niemals auf ein totes Pferd setzen.

Vielleicht haben wir ja bald ein NetBSD/kMinix3

Rump Kernel ist uebrigens auch ganz toll
 
Ich wollte mal Minix ausprobieren, aber als darüber mal länger nachgedacht habe, wie es ist, keinen grafischen Web-Browser zu haben, war mir das am Ende doch zu abgefahren.
 
rubricanis schrieb:
Irgendwann werde ich mir auch Inferno mal anschauen...
Zum Vergrößern anklicken....

Es lohnt sich wirklich, ich empfehle allerdings vorher noch einen Umweg über Plan 9 From Bell Labs zu nehmen.
Ich persönlich finde ja, dass FreeBSD weniger Features von Apple als viel mehr von Plan 9 und Inferno übernehmen sollte. Vielleicht habe ich ja irgendwann mal die Zeit und Muse, per Process Namespaces in FreeBSD nachzubauen, Linux hat das ja schon. Ist allerdings ohne stapelbare Mountpoints nicht ganz so cool nutzbar…
 
NetBSD lebt ja noch, aber sicher wird die laxe Führung der Foundation noch zum Sargnagel. Ohne den Zustrom der vielen Japaner und Pkgsrc wäre man am Ende. Zudem waren die Teilnahmen an den GSoC selten früchtetragend. Auch die Changes bei den Releases werden immer weniger und häufiger kommt da lediglich ein Update oder Treiberport. Auch der Spendenstand zeigt wie wenig Interesse das Projekt generiert, da Spenden die Mitglieder überwiegend selbst.
Und zu launchd, es gibt nicht wenige die dem Konzept was abgewinnen können. Aber die Richtung näher an MacOS wäre sich immer im Desktop-Bereich interessant, doch wird niemals der Stand auf Linux eingeholt werden.
 
@rubricanis DragonFly ist toll, was Features, aber auch was Dinge wie Performance angeht (schlägt FreeBSD da in vielen Bereichen). Auch mit so Sachen, wie Intel-Grafik waren sie früh dran, oder damals mit den USB-Problemen. Nur User gibt's halt recht wenige und Projekte ohne User sind nicht wirklich "groß". ;)

Und natürlich braucht man User für Dinge, wie Support und es ist immer gut, wenn ein paar Unternehmen auf die eine oder andere Art dahinter stehen. Ist ein wenig traurig. Für den Produktiveinsatz fehlt quasi nichts, man hat ein paar Vorteile (und Nachteile) gegenüber anderen Systemen, aber es ist etwas leise und hat deutlich weniger Hype als die Anderen. FreeBSD ist das Ding, das Netflix und WhatsApp verwenden und OpenBSD hat ja in letzter Zeit ordentlich Wirbel gemacht. Bei NetBSD und DragonFly herrscht Stille. Da wird zwar fleißig gehacked, aber eben eher im Stillen und im Endeffekt können gehen einem dann womöglich auch irgendwann die Entwickler aus. Ist zwar etwas traurig, aber was will man machen.
 
NetBSD hat zu viel Verwaltung drumrum. Die hacken nicht, die arbeiten. Kein Wunder geht's da nicht voran.
 
das.chaos schrieb:
seL4 ist *imho* alter Wein in neuen Schlaeuchen , ...
Zum Vergrößern anklicken....
Witzig das gerade aus dem BSD-Lager zu hören.:) SeL4 ist einfach die wohl fortgeschrittenste Inkarnation des L4 Kernels, also das Ergebnis von 20 Jahren kontinuierlicher Entwicklung.

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Mir liegt ja jeder Art von Patriotismus fern aber interessant finde ich schon dass in diesem Bereich deutsche Entwicklungen und Entwickler eine maßgebliche Rolle spielen. Da ist an den viel gescholtenen deutschen Unis (Karlsruhe, Dresden etc) wohl einiges gut auf den Weg gebracht worden...
 
Und hier ein wie ich meine interessates Beispiel für das auf was das hinauslaufen kann.
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
Ich denke nicht dass aus diesen Ansätzen etwas entstehn wird was die OS-Landschaft wesentlich verändern wird. Dazu ist die Macht des Faktischen einfach zu groß. Ich vermute aber das wesentliche Prinzipien nach und nach in die großen Systeme einfließen und diese verändern werden da a.G. einer überbordenden Komplexität der Betriebssyteme und steigernden Anforderungen an Sicherheit, Wartbarkeit und Veränderbarkeit denen nichts anderes übrig bleiben wird. Das wird seine Zeit dauern aber im Kern werden sich die Ideen von Tannbaum und Liedke durchsetzen. Zunächst aber werden Hubbard & Co mit Mach weiterspielen und eine Layer über die andere stapeln....;)
 
Moin @rubricanis, ein Dankeschoen fuer die Verweise auf die (horizont erweiternden) Vortraege!!!

rubricanis schrieb:
Zunächst aber werden Hubbard & Co mit Mach weiterspielen und eine Layer über die andere stapeln....;)
Zum Vergrößern anklicken....

Och, eine Schichtenarchitektur ist schon sinnvoll, bspw. wurden mit S*stemD,
meiner Meinung nach, einige Userspacekomponenten von sich unterscheidenden
hirarchischen Ebenen in das Flachland verlagert, was letztendlich nicht so schoen
ist. :D

Btw, Hubbard & Co haben mich, bzgl. deren Ideen, irgendwie angefixt.
 
Habe mal ein bisschen mit systemd zu tun gehabt. Ein paar nette Erfahrungen zum Thema "einfacher" und unified. Habe da zwei Systeme, eines auf Debian-Basis und eines auf Arch Linux Basis, aber hey, beides systemd. Also mal mit journalctl gespielt...

Erstes Problem:
Das von Debian abgeleitete System hat (das ältere?) systemd-journalctl und Arch das (moderne?) journalctl.

Wäre alles nicht so schlimm, wenn sie denn nicht unterschiedlich funktionieren würden. Erster Punkt war, dass systemd-journalctl kein -u (unit file) flag hat. Puh, da habe ich aber nochmal Glück gehabt. Verwendet man eben sowas, wie _SYSTEMD_UNIT=sshd.service. Das sollte auf beidem klappen. Tut es auch. Um sshd vs ssh, was da auch noch ein Problem war habe ich mich auch schon gekümmert.

Nun ist ja journalctl so nett und hat ein paar Features, wie JSON-Ausgabe, einen "-f"-Switch (wie tail -f) und ein -n (wie tail -n). Damit könnte man ja theoretisch sowas machen wie "-o json -n0 -f" um zukünftige Events auf als JSON zu bekommen, also das ganze mal auf Arch probiert, was auch ganz gut funktioniert, juhu!

Dann einfach mal auf Debian probiert, laut man-page alles da, ausgeführt und gleich drei Probleme:
  • Pretty-Printed JSON, also mal nicht per Line einlesbar, aber okay... (ist immerhin noch zu haben mit der neuen Version)
  • -n 0 ist -n1 OUCH! Warum das?!
  • Das JSON ist hier ein Array von Objekten, das heißt man hat mal eine Zeile mit "[", das quasi nie zugeht.
Soll heißen, es gibt ein System, das sich um Logs kümmert, das ein wenig API-mäßig aufgebaut ist (JSON-Output und so) und das erste was man hat sind inkompatible Versionen. Dafür hat man aber einen konfigurierbaren eingebauten Pager.

Sorry, für den Rant, aber die erste Version des Programms lief auf diversen Systemen recht einheitlich gut und hier braucht man schon allein für systemd Weichen ohne Ende und bei Systemd ist ja ein beliebtest Argument, dass es viel einfacher ist da einfach was dran zu coden, aber wenn das JSON-Interface, das wohl am Ehesten in die Richtung geht schon mehr Probleme macht als einfach Text zu parsen und -n0 gleich -n1 ist, dann denke ich nicht, dass dieses Argument haltbar ist.

Übrigens: Das ist lediglich ein Rant, kein Beweis für irgendeswas. Ich will damit nicht sagen, dass systemd ganz allgemein so schlecht ist sondern einen Einzelfall schildern, um darzustellen, dass ich das Argument, dass es die Dinge einfacher macht nicht nachvollziehen kann.
 
Das ist halt die Seuche, wenn etwas wächst, statt designt zu werden. Nothing to see here, move along. Sogar der Linux-Kernel selbst hat doch diese Philosophie, jederzeit "Altlasten" (i.e. shit design in the first place) abzustoßen und alle können gucken, wo sie bleiben.
 
Ich glaube das ist der Grund, warum es gerade bei so zentralen Dingen (zentral im Sinne, dass viel verschiedene Software damit zu tun hat) wichtig ist, dass die Dinge klein bleiben und auch kleine, simple Interfaces haben. Ich bin ja nicht ganz dagegen, dass Dinge auch mal explizit keine Abwärtskompatibilität haben, bzw. eben was neues erstellt wird, das das Alte ersetzt. Nur ist jetzt systemd nicht soooo alt und zumindest ist die Möglichkeit des Beibehalten eines alten Formats mit entsprechenden Optionen ja nicht unbedingt, die große Herausforderung. Und zu dem -n 0 Beispiel. Das ist doch eher was wovon man auch in einer ersten Version ausgehen sollte, dass das richtig (bzw. wie in tail, das man nachahmt) funktioniert, oder?

Alternative Möglichkeiten dazu ist natürlich dass man systemd-journalctl auch drin ließe. Das ist eine Altlast, aber da das Interface jetzt nicht so arg unterschiedlich ist denke ich, dass sich da der Wartungsaufwand in Grenzen hält.

Naja, jedenfalls ein Beispiel warum simple Software vielleicht doch keine so schlechte Idee ist. ;)
 
TCM schrieb:
Das ist halt die Seuche, wenn etwas wächst, statt designt zu werden.
Zum Vergrößern anklicken....

Das gute alte big design up front. :)
Ich bin mehr der Freund von little design up front.

Athaba schrieb:
Und zu dem -n 0 Beispiel. Das ist doch eher was wovon man auch in einer ersten Version ausgehen sollte, dass das richtig (bzw. wie in tail, das man nachahmt) funktioniert, oder?
Zum Vergrößern anklicken....

So wie ein Programm, das JSON-Output verarbeitet, schon in der ersten Version mit Multi-Line-Output umgehen können sollte. ;)

Athaba schrieb:
Alternative Möglichkeiten dazu ist natürlich dass man systemd-journalctl auch drin ließe. Das ist eine Altlast, aber da das Interface jetzt nicht so arg unterschiedlich ist denke ich, dass sich da der Wartungsaufwand in Grenzen hält.
Zum Vergrößern anklicken....

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.

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... :ugly:
 
Ich sage ja nicht, dass das komplette Design von vornherein stehen muss. Aber man sollte schon konsistent bleiben und bei jedem Furz, den man macht, mal nachdenken, wie das in Zukunft aussehen könnte.

Die Kunst ist halt, vorher mal zu gucken und zweimal zu überlegen, wie das sinnvoll erweitert werden könnte - quasi ein Meta-Design - anstatt das hinzukotzen, was man gerade braucht und das dann jeden Tag wieder umzuwerfen.

Ob das 72-Spalten-Beispiel jetzt aus "big design up front" resultiert, wage ich mal zu bezweifeln.
 
Azazyel schrieb:
Das gute alte big design up front. :)
Ich bin mehr der Freund von little design up front.
Zum Vergrößern anklicken....
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. ;)
Zum Vergrößern anklicken....
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.
Zum Vergrößern anklicken....

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... :ugly:
Zum Vergrößern anklicken....
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.
 
Zuletzt bearbeitet:
@TCM: Für Skriptsprachen gibt es Hinter und Linter, etc. Wollte das mal wo einführen. Resultat: Es wurden config files angelegt und ins Repository gelegt, die den Linter so konfigurieren, dass er mit dem Code in dem jeweiligen Repo keine Warnings mehr ausgibt. :ugly:

Du siehst: Programmierer lösen ihre Probleme so effizient wie möglich. :rolleyes:
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben