Warum immer diese neue Einarbeitung

[Meillo]

Ansonsten, man kann immer noch die Journals abschalten und alles an rsyslogd durchreichen.

Dieses Durchreichen ist aber eine zusätzliche potenzielle Fehlerquelle. Wie ich schon früher schrieb, auch ich nutze heute journalctl, weil alle Aufsätze auf Systemd die mögliche Fehlerkette verlängern.

Wenn du das Durchreichen schlecht findest, dann kann man keine Vielfalt realisieren. Sie braucht Schnittstellen und Abstraktionen und damit mehr Schichten und durchreichende Stellen. Die einzige Alternative dazu sind allmaechtige Monolithen, die du bestimmt noch weniger magst.

Im konkreten Fall kenne ich mich technisch nicht genug aus: Kann man *statt* journald auch rsyslogd ankoppeln oder koppelt man den rsyslogd an den journald an? IMO waere der beste Ansatz, dass es ein (Text-)Interface zum Logging gibt, an das man dann, je nach Praeferenz rsyslogd, journald oder sonstwas ankoppeln kann. Diese Wahlmoeglichkeiten stehen dabei alle gleichwertig nebeneinander.

Aber ist es nicht der gleiche Fall wenn das verwendete Dateisystem eines ist das auf dem anderen System nicht unterstuetzt wird? Dann kannst du genauso wenig debuggen, wie wenn dein Rettungssystem kein Systemd hat. Oder wenn du ein Software-Raid hast und keine Raid-Software auf dem Rettungssystem.

Solange man diese Software voraussetzt, ist die Welt gut. Du (hikaru) willst sie aber nicht voraussetzen.

Bei einem Dualboot-System würde ich natürlich Dateisysteme einsetzen, die beide Betriebssysteme gegenseitig zumindest lesen können. Als ich in grauer Vorzeit z.B. noch Linux und Windows nutzte, hatte ich unter Windows einen 3rd-Party-Treiber installiert, der zumindest zuverlässig ext2 lesen konnte.
Ich denke daher schon, dass ich diese Software voraussetzen kann. Ich schrieb ja im Szenario auch, dass BSD das Linux-Dateisystem mounten kann.

Waere es demnach fuer dich kein Problem mehr, wenn es journalctl fuer BSD gaebe? Das waere doch aequivalent zum ext2-mount-Backend unter BSD.

[DeletedUserReAsG]

Deshalb schrieb ich ja, dass kein anderes Linux zur Verfügung steht.

Das rangiert in meiner Skala gleich hinter „kein Backup – kein Mitleid“. Wer nur einen Rechner hat, sollte zumindest ’nen USB-Stick oder eine Scheibe mit grml oder so vorhalten. Abgesehen davon haben alle ernstzunehmenden Distributionen ein weitgehend unabhängiges Fallback-/Rescue-/Minimalsystem, so dass es schon ziemlich ungünstig knallen müsste, um da nicht mehr ohne externes System ranzukommen. Und in dem Fall würde es einen dann wohl auch nicht mehr weiterbringen, dass man das Logfile immerhin in Windows’ Notepad lesen könnte

TL;DR: ich halte das Argument, dass man ja zum Zugriff auf journal-Dateien ein Tool brauchen würde, und das journal daher doof wäre, für vorgeschoben.

[Lord_Carlos]

Die kombination aus kein system vorhanden was journal lesen kann und journal zu Text Datei nicht vertrauen hoert sich arg nach einem nischen Problem an.

[hikaru]

Systemd logt sowieso nicht selbst, das macht journald.

Bereitet journald nicht nur die Logs menschenlesbar auf? Und hängt rsyslogd wirklich an systemd und nicht an journald?
Wie dem auch sei, selbst wenn rsyslogd unabhängig von journald ist, ist es immer noch auf die Schnittstellenkooperation von Systemd angewiesen. Die ist momentan gegeben, aber da Systemd mit journald einen direkten Konkurrenten zu rsyslogd im eigenen Hause hat, könnte diese Kooperation jederzeit entfallen. Systemd ist natürlich FLOSS, weshalb rsyslogd sich an Änderungen der Schnittstelle anpassen könnte, aber es wäre zumindest vorstellbar, dass Systemd bei jedem Release die Schnittstelle ändert.

Was die Auswertung angeht, so geht das selbstverständlich offline. Die Journals sind letztllich nur Dateien, die man mit dem Programm journalctl auch offline auswerten kann. Man braucht dazu aber halt ein Linux, weil journalctl unter Windows oder BSD nicht zur Verfügung steht.

Eben diesen Linuxism kritisiere ich ja.

Ich logge aber trotzdem immer noch mit rsyslogd, Die Journals habe ich komplett abgeklemmt, weil ich Logs nicht doppelt haben will.

Geht das überhaupt bzw. ist das vorgesehen? Alles was ich dazu gefunden habe sind eher alte Threads und Blogeinträge in denen es nach einem Hack klang, journald tatsächlich stillzulegen.

Wenn du das Durchreichen schlecht findest, dann kann man keine Vielfalt realisieren.
[..]
IMO waere der beste Ansatz, dass es ein (Text-)Interface zum Logging gibt, an das man dann, je nach Praeferenz rsyslogd, journald oder sonstwas ankoppeln kann.

Eben das ist für mich der springende Punkt:
Die Schnittstelle an die alle Logger andocken, sollte mMn ein Text-Interface sein und kein Binäres, das erst der Logger (potenziell fehlerträchtig) in Text umwandelt.

Waere es demnach fuer dich kein Problem mehr, wenn es journalctl fuer BSD gaebe? Das waere doch aequivalent zum ext2-mount-Backend unter BSD.

Es wäre für mich ein geringeres Problem, wenn Systemd im Allgemeinen und journalctl im Speziellen kein Linuxism wäre. Ob das Alternativsystem dann BSD, Solaris oder Windows wäre, ist mir egal. Die Möglichkeit zur Portabilität müsste von den Systemd-Devs vorgesehen sein.
Das Problem der originär binären Logs löst das freilich nicht.

Das rangiert in meiner Skala gleich hinter „kein Backup – kein Mitleid“. Wer nur einen Rechner hat, sollte zumindest ’nen USB-Stick oder eine Scheibe mit grml oder so vorhalten.

Ich habe einen ganzen Zoo von Rechnern, aber auf Reisen nehme ich jeweils nur einen mit. Eben wegen „kein Backup – kein Mitleid“ habe ich praktisch immer auch einen Rettungsstick dabei, aber das entspringt einer gewissen "EDC-Mentalität" meinerseits und lässt sich keinesfalls verallgemeinern.

TL;DR: ich halte das Argument, dass man ja zum Zugriff auf journal-Dateien ein Tool brauchen würde, und das journal daher doof wäre, für vorgeschoben.

Es ist deshalb doof, weil das einzig verfügbare Tool nicht portabel ist. Auch zum Lesen von Textdateien brauche ich ein Tool, aber solch ein Tool ist überall verfügbar und es gibt Hunderte die mehr oder weniger geeignet sind.

Die kombination aus kein system vorhanden was journal lesen kann und journal zu Text Datei nicht vertrauen hoert sich arg nach einem nischen Problem an.

Es wird zu einem Nischenproblem, wenn du zwischen beiden Halbsätzen eine Kausalität herstellst. Für mich sind das zwei getrennte Punkte die jeder für sich problematisch sind.
Zur Zeit ist es lediglich so, dass beide Punkte die Schwäche des jeweils anderen Auffangen: Wenn ich mal kein Journal lesen kann, dann kann ich noch auf die rsyslogd-Logs zurückgreifen. Andersrum, wenn ich rsyslogd nicht vertraue, kann ich direkt das Journal lesen. Unbequem ist lediglich, dass ich im Zweifelsfall beides lesen können muss.
Aber aus Systemd-Sicht ist rsyslogd eben ein alter Zopf der abgeschnitten gehört, genau wie SysVInit. Dass beides noch funktioniert ist ein kulantes Zugeständnis an die Nutzer. Bei SysVInit sehen wir bereits Auflösungserscheinungen (in Debian nicht mehr RC-würdig). Wenn das auch bei rsyslogd einsetzt und damit dessen Log nicht mehr vertrauenswürdig ist, dann geht rsyslogd als Fallback für ein unlesbares Journal verloren.

[MSfree]

Bereitet journald nicht nur die Logs menschenlesbar auf?

Nein. Logs kommen in der Regel über die C-Funktion syslog zustande. Das ist eine reine Textscnittstelle, die dem Meldungstext noch ein paar Attribute wie Datum/Zeit und Hostname voranstellt. Jornald schreibt derart empfangene Texte dann in seine Binärdatei. Im Grunde macht journald also aus einer menschenlesbaren Meldung eine nur noch maschinenlesbare Information.

Und hängt rsyslogd wirklich an systemd und nicht an journald?

Die wichtigste Quelle ist die syslog-Schnittstelle, dann gibt es noch die klog-Schnittstelle für Kernelmeldungen. Die Ausgaben von Programme, die nicht als Daemon konzipiert waren und auf stdout schreiben, werden nun auch (und das ist erst durch systemd möglich) abgefangen und über die syslog-Schnittstelle verschickt.

Letztlich dockt journald an diese syslog-Schnittstelle an. Das Weiterzureichen von Meldungen an rsyslog veranlaßt meines Wissens nach journald. Man braucht also journald, ganz lsowerden tut man den nicht.

Wie dem auch sei, selbst wenn rsyslogd unabhängig von journald ist, ist es immer noch auf die Schnittstellenkooperation von Systemd angewiesen.

Die meisten Daemons loggen über syslog, und solange keiner diese Schnittstelle abschafft (obwohl, Lennart ist alles zuzutrauen) ist es eher umgekehrt, systemd hängt von der syslog-Schnittstelle ab.

Ein wesentlicher Punkt von rsyslogd ist, daß dieser netzwerkfähig ist. Logging auf einen zentralen Loghost ist mit journald nicht möglich. Wobei rsyslogd hier allerdings unverschlüsselt kommuniziert, was potentiell MiM-Attacken ermöglicht. Schadsoftware könnte z.B. verhindern daß gewisse Logs an den Loghost geschickt werden, z.B. wenn sich root an einem Rechner anmeldet, was die Forensik erschweren kann.

Im Moment sehe ich rsyslogd noch nicht in Gefahr, aber was nciht ist, kann ja noch kommen.

[hikaru]

Logs kommen in der Regel über die C-Funktion syslog zustande. Das ist eine reine Textscnittstelle,
[..]
Letztlich dockt journald an diese syslog-Schnittstelle an. Das Weiterzureichen von Meldungen an rsyslog veranlaßt meines Wissens nach journald. Man braucht also journald, ganz lsowerden tut man den nicht.

Dann würde sich ein Großteil meiner Kritik schon erledigt haben, wenn man journald aus dieser Kette entfernen und rsyslogd direkt auf die syslog-Schnittstelle zugreifen würde.

Jornald schreibt derart empfangene Texte dann in seine Binärdatei. Im Grunde macht journald also aus einer menschenlesbaren Meldung eine nur noch maschinenlesbare Information.

Das grenzt ja an einen Schildbürgerstreich.

[Meillo]

Logs kommen in der Regel über die C-Funktion syslog zustande. Das ist eine reine Textscnittstelle,
[..]
Letztlich dockt journald an diese syslog-Schnittstelle an. Das Weiterzureichen von Meldungen an rsyslog veranlaßt meines Wissens nach journald. Man braucht also journald, ganz lsowerden tut man den nicht.

Dann würde sich ein Großteil meiner Kritik schon erledigt haben, wenn man journald aus dieser Kette entfernen und rsyslogd direkt auf die syslog-Schnittstelle zugreifen würde.

Warum ist das denn nicht so? Das waere doch die simpelste und offensichtliche Umsetzung. Warum also ist Journald essenziell?

Jornald schreibt derart empfangene Texte dann in seine Binärdatei. Im Grunde macht journald also aus einer menschenlesbaren Meldung eine nur noch maschinenlesbare Information.

Das grenzt ja an einen Schildbürgerstreich.

Ich finde das in Ordnung und notwendig so. Wenn man die Logs als Datenbank haben will, ist diese Umwandlung noetig (fuer die Geschwindigkeit). Mir ist das jedoch gleich, wenn man die Wahl hat. Entscheidend ist, dass die Schnittstelle textuell ist. Je nach spezifischem System kann man die Logs dann lokal binaer speichern, lokal textuell speichern, nach /dev/null pipen, an einen entfernten Log-Server uebermitteln, per Mail verschicken, ausdrucken, usw.

[DeletedUserReAsG]

Eben wegen „kein Backup – kein Mitleid“ habe ich praktisch immer auch einen Rettungsstick dabei, aber das entspringt einer gewissen "EDC-Mentalität" meinerseits und lässt sich keinesfalls verallgemeinern.

Gut – die Frage ist ja: welcher normale User hat auf Reisen einen Rettungsdatenträger dabei, mit dem er die Logs eines unbootbaren Systems einsehen kann, weil er unterwegs so an seinem System bastelt, dass es unbootbar wird?

Ich denke: wer an seinem System so rumhantiert, dass die Gefahr besteht, dass es nicht mehr hochkommt, und dann kein passendes Live-/Rettungssystem vorhält, hat halt Pech gehabt. Und wer ein passendes Live-/Rettungssystem vorhält, findet darauf auch journalctl und Zubehör. Wer natürlich ’n Linux auf dem Laptop hat, und ein BSD-Rettungssystem in der Tasche, der hat’s irgendwie auch nicht anders verdient ….

Außerdem:

Es ist deshalb doof, weil das einzig verfügbare Tool nicht portabel ist. Auch zum Lesen von Textdateien brauche ich ein Tool, aber solch ein Tool ist überall verfügbar und es gibt Hunderte die mehr oder weniger geeignet sind.

Das Journal beinhaltet sämtliche Logeinträge als Text, der sich recht gut mit etwa strings extrahieren lässt, und nach etwas Aufarbeitung nicht anders aussieht, als das herkömmliche Log vom syslogd. Da braucht’s nicht mal gehobene grep-Konstrukte, zumindest mein Gehirn erkennt die Klartext-Logeinträge ohne weitere Anstrengung. Abgesehen davon: was genau hindert dich, einen Journal-Viewer für das von dir bevorzugte System zusammenzustricken? Ist ja nicht so, als wäre das Journal mit nur unter Linux verfügbaren Algorithmen kryptographisch gesichert ….

Eben diesen Linuxism kritisiere ich ja.

Das kritisiere ich wiederum: warum ist’s ein Problem, dass es OS-spezifische Lösungen gibt? Welchen Anspruch haben User eines ganz anderen Systems darauf, dass Linuxuser und -entwickler sich einschränken, um mit ihrem System kompatibel zu bleiben? Ich finde viele der neueren linuxspezifischen Sachen, wie etwa cgroups oder das Journal, ganz prima, und ich fände es nicht gut, darauf verzichten zu müssen, weil’s die unter ’nem ganz anderen OS ja auch nicht gibt. Wenn du mit linuxspezifischen Lösungen ein Problem hast, dann nutze doch etwas anderes? Wenn du meinst, du müsstest von dem von dir bevorzugten System aus auf die Linux-Logs zugreifen können, dann bau dir doch etwas dafür (und gib’s auch den anderen Usern deines Systems)?

Szenario: Die Maschine ist gerade unvermittelt abgeschmiert. Linux kommt nicht mehr hoch, das Dualboot-BSD von dem aus du das debuggen willst aber schon. Das Linux-Dateisystem ist mountbar aber nicht chroot-bar. Du vermutest ein Problem im Bereich deiner Datenträger. Ein weiteres Linux als Rettungssystem steht nicht zur Verfügung.
Aufgabe: Extrahiere alle Logeinträge die im Zusammenhang mit Datenträgern stehen, inklusive menschenlesbarer Timestamps!

Lösung: ich fahre das BSD hoch, und schreibe mir von dort aus das grml-Image auf einen der drölfzig USB-Sticks, die hier rumfliegen. Damit boote ich die Kiste, mounte die Linux-Dateisysteme und wenn das fehlerfrei funktionierte, chroote ich in das Linuxsystem, wo ich dann mit den dafür vorgesehenen Werkzeugen erheblich angenehmer arbeiten kann, als von einem Fremd-OS aus mit Plaintext-Logs und ihren eingeschränkten Informationen. Gibt es beim Mounten schon Fehler, kann ich mich mit den nativen Tools für das Dateisystem (oder LVM oder RAID oder wo auch immer es hakt), die auf meinem Linux-Livesystem vorhanden sind, darum kümmern. Wenn sich z.B. herausstellt, dass der Bootloader neu geschrieben werden, oder ein Paket reinstalliert werden muss, lässt sich das von ’nem Fremd-OS aus sowieso nicht bewerkstelligen – man würde also so oder so zu einem Live-Linux greifen.

[spiralnebelverdreher]

Hallo zusammen,
ich beschäftige mich mit Linux seit 1995.
....

Seid Ihr Linux-Fachleute nur Nerds, die 24/7 am Rechner hängen? Es gibt auch andere Prioritäten, wie z.B. neben Beruf, Familie, Kinder auch so etwas wie Hausbau, Garten, Kinderzimmer umgestalten, mit Corona fertig werden, das älteste Kind wird volljährig, Stress mit der Schule, Entlassungwelle in der Firma, Krankheiten im engeren Familienkreis etc...

Ich habe die Erfahrung gemacht, dass die Umstellung der Rechner meiner Familie (Frau, Kind, Schwiegermutter) von Windows auf Linux (debian stable) den Betreuungsaufwand der Rechner deutlich verringert hat. Ich habe jetzt mehr Zeit für meine Hobbies und die Familie, aber auch für die weniger schönen Aspekte wie Krankheiten im Familienkreis.

Was mich bei deinen früheren Posts schon sehr wundert, wie oft du schon im Betreff das Wort "Schikane" verwendest. Falls du den Eindruck hast, die Linux Community würde mit Absicht gegen dich arbeiten wäre es vielleicht angebracht, dass du dich für ein anderes Betriebssystem entscheidest.

[KP97]

Das ist und bleibt ein Troll und sollte ignoriert werden, ganz wie @MSfree schon schreibt.
Fallt doch nicht immer darauf herein, opfert Eure Zeit und streitet womöglich noch.
Das ist es doch, was solche Typen einzig und allein bezwecken.

[TRex]

Das ist und bleibt ein Troll

was solche Typen einzig und allein bezwecken.

Die Anschuldigungen halte ich für moralisch fragwürdig. Ich glaube immer noch, dass der TE hier nur alle halbe Jahre zum ranten vorbeikommt und die Anwesenden ganz alleine dafür verantwortlich sind, dass hier schon fünf Seiten voller unnötiger und nutzloser Beiträge stehen. Ich empfehle https://de.wikipedia.org/wiki/Hanlon%E2%80%99s_Razor

[DeletedUserReAsG]

Ich glaube immer noch, dass der TE hier nur alle halbe Jahre zum ranten vorbeikommt und die Anwesenden ganz alleine dafür verantwortlich sind, dass hier schon fünf Seiten voller unnötiger und nutzloser Beiträge stehen.

Wenn sie für jeden unnötig und nutzlos sein würden, wären sie nicht geschrieben worden.

[hikaru]

Gut – die Frage ist ja: welcher normale User hat auf Reisen einen Rettungsdatenträger dabei, mit dem er die Logs eines unbootbaren Systems einsehen kann, weil er unterwegs so an seinem System bastelt, dass es unbootbar wird?

Warum gehst du von mutilliger Bastelei aus und nicht von einem Unfall?

Das Journal beinhaltet sämtliche Logeinträge als Text, der sich recht gut mit etwa strings extrahieren lässt, und nach etwas Aufarbeitung nicht anders aussieht, als das herkömmliche Log vom syslogd. Da braucht’s nicht mal gehobene grep-Konstrukte, zumindest mein Gehirn erkennt die Klartext-Logeinträge ohne weitere Anstrengung.

Dann bitte ich dich, für meine an willy gestellte Aufgabe eine Lösung zu präsentieren!

Abgesehen davon: was genau hindert dich, einen Journal-Viewer für das von dir bevorzugte System zusammenzustricken?

Meine Faulheit, mir die nötigen Kenntnisse anzueignen.

Das kritisiere ich wiederum: warum ist’s ein Problem, dass es OS-spezifische Lösungen gibt? Welchen Anspruch haben User eines ganz anderen Systems darauf, dass Linuxuser und -entwickler sich einschränken, um mit ihrem System kompatibel zu bleiben?

Es ist kein Problem, dass es OS-spezifische Lösungen gibt. Die vor diese Lösung existierende Lösung war aber nicht OS-spezifisch und die neue Lösung, die anerkanntermaßen Vorteile hat, ist nun OS-spezifisach. Das ist ein Rückschritt in diesem Punkt der neuen Lösung und ich kritisiere, das sich die Entwickler der neuen Lösung wider besseren Wissens für diesen Rückschritt entschieden haben.

Wenn du meinst, du müsstest von dem von dir bevorzugten System aus auf die Linux-Logs zugreifen können, dann bau dir doch etwas dafür (und gib’s auch den anderen Usern deines Systems)?

Dazu fehlen mir persönlich die Fähigkeiten. Es ist ja auch nicht so, dass ich allein mit meiner Meinung wäre. Das schiere Ausmaß der Diskussion um die Linuxismen in Systemd war nun wirklich nicht zu übersehen. Es gab ja in der BSD-Community sogar Bestrebungen, in irgendeiner Weise Systemd-kompatibel zu werden - idealerweise indem man es selbst nutzen könnte, notfalls aber auch nur um damit interagieren zu können. Seitens Systemd gab es da aber so gut wie keine Kooperation.

Lösung: ich fahre das BSD hoch, und schreibe mir von dort aus das grml-Image auf einen der drölfzig USB-Sticks, die hier rumfliegen.

Woher hast du das grml-Image? Im Szenario steht ausdrücklich, dass du keinen Zugriff auf ein anderes Linux als die kaputte Installation hast!
Wie es dazu kam kannst du dir gern selbst aussuchen (auf Reisen ohne Netz, nicht dein Rechner, etc.), ist aber letztendlich irrelevant. So sieht die Situation aus, vor der du stehst.

[DeletedUserReAsG]

Warum gehst du von mutilliger Bastelei aus und nicht von einem Unfall?

Weil ich seit ~15 Jahren kein System mit so einem Unfall mehr hatte, dass es sich nicht booten ließe. Insofern fällt’s mir gerade schwer, mir da was vorzustellen, das dann von ’nem anderen System aus behoben werden könnte. Aber vielleicht hast du ja ein (nicht zu sehr an den Haaren herbeigezogenes, wenn möglich) Beispiel?

Dann bitte ich dich, für meine an willy gestellte Aufgabe eine Lösung zu präsentieren!

Ich habe Livesysteme mit den passenden Werkzeugen zur Hand, wenn der unwahrscheinliche Fall tatsächlich mal eintreten sollte, dass ich sie benötige. Und mir reicht die Ausgabe von strings, wenn der noch unwahrscheinlichere Fall eintreten sollte, dass ich keinen Zugriff auf ein Livesystem, dafür aber irgendein BSD vorliegen hätte, das aus irgendwelchen wundersamen Gründen sogar sowohl dm_crypt, als auch LVM sauber aufmachen kann. Kurz: ich sehe da nicht mal eine sinnvolle Aufgabe.

Meine Lösung habe ich ja beschrieben: ich würde mir von da aus das passende System auf ’nen Stick schreiben, und mit dessen Hilfe bequem mit den nativen Werkzeugen arbeiten können: sowohl dm_crypt aufschließen, die LVM-Volumes richtig zusammenstecken, die Dateisysteme ordentlich mounten, in das kaputte System chrooten, das Journal mit dem richtigen Werkzeug bequem und effektiv in Augenschein nehmen und ggf. Fehler ebenso mit den dafür vorgesehenen und passenden Werkzeugen beheben.

Warum sollte ich also Arbeit in etwas stecken, von dem du was haben könntest, das mir aber nichts bringt?

Abgesehen davon: wie würde es denn laufen, wenn ich den Nachmittag investieren würde? Ich würde ein Pythonscript präsentieren, das dir das Journal im alten syslog-Format ausgibt, woraufhin du vermutlich „aber aber aber … aber du kannst nich davon ausgehen, dass Python überall verfügbar ist!!k“ antworten würdest. Deine Antipathie dem Neuen gegenüber ist leider unübersehbar, da würde so ein Script genau gar nichts dran ändern. Verlorene Zeit wäre das.

Meine Faulheit, mir die nötigen Kenntnisse anzueignen.

… und weil du zu faul bist, sollen alle anderen auf die Vorteile des Neuen verzichten?

ich kritisiere, das sich die Entwickler der neuen Lösung wider besseren Wissens für diesen Rückschritt entschieden haben.

Die neue Lösung bietet nunmal Möglichkeiten, die sich ohne die Aufgabe der absoluten Kompatibilität nicht umsetzen ließen. Ich meine, es geht doch nicht um irgend’ne Anwendung, die nun nicht mehr auf ’nem anderen System zum Laufen zu bekommen wäre, sondern um ein Initsystem für Linux, das niemals unter einem anderen System laufen sollte. Warum sollte da die Kompatibilität zu irgendwas anderem gewahrt werden?

Woher hast du das grml-Image?

Sagen wir’s so: ich bin nicht jemand, der am 31.12. total überrascht ist, dass der Kalender nicht weitergeht.

Gegenfrage: du hast dein nicht mehr bootendes Linuxsystem mit syslog. Du kannst das Dateisystem unter deinem Windows mit dem Treiber (woher hast du den eigentlich in der Situation? Vorher besorgt? Warum ginge das mit einem grml-Image nicht?) oder unter BSD gar nativ mounten (weil du halt eines der alten FS einsetzt), schaust nun ins Log und findest, dass der Bootloader neu geschrieben oder das initramfs oder ein DKMS-Treiber neu gebaut werden müssen – wie genau hilft’s dir dabei, dass du das Log unter deinem Fremdsystem hübsch formatiert lesen konntest, statt dich mit der etwas unübersichtlicheren Ausgabe von strings begnügen zu müssen? Nein, ich bleibe dabei: ich halte deine Szenarien für sehr theoretisch, um nicht zu sagen, völlig praxisfern konstruiert.

[hikaru]

Warum gehst du von mutilliger Bastelei aus und nicht von einem Unfall?

Weil ich seit ~15 Jahren kein System mit so einem Unfall mehr hatte, dass es sich nicht booten ließe. Insofern fällt’s mir gerade schwer, mir da was vorzustellen, das dann von ’nem anderen System aus behoben werden könnte. Aber vielleicht hast du ja ein (nicht zu sehr an den Haaren herbeigezogenes, wenn möglich) Beispiel?

Nichts leichter als das:
Ein langsam sterbender Datenträger.

Ich habe Livesysteme mit den passenden Werkzeugen zur Hand, wenn der unwahrscheinliche Fall tatsächlich mal eintreten sollte, dass ich sie benötige. Und mir reicht die Ausgabe von strings, wenn der noch unwahrscheinlichere Fall eintreten sollte, dass ich keinen Zugriff auf ein Livesystem, dafür aber irgendein BSD vorliegen hätte, das aus irgendwelchen wundersamen Gründen sogar sowohl dm_crypt, als auch LVM sauber aufmachen kann. Kurz: ich sehe da nicht mal eine sinnvolle Aufgabe.

Weil du also auf alles vorbereitet bist, änderst du einfach die Aufgabenstellung. Wenn du keine Lösung der gestellten Aufgabe anbieten kannst, dann spare es dir doch bitte, eine nicht zur Aufgabenstellung passende Lösung zu präsentieren!
In der Schule stünde unter deiner Lösung: "Aufgabenstellung verfehlt. 6"

Warum sollte ich also Arbeit in etwas stecken, von dem du was haben könntest, das mir aber nichts bringt?

Um darzulegen, dass du die gestellte Aufgabe lösen kannst und nicht irgendeine andere, die du dir selbst ausgedacht hast. Warum sonst solltest du dich überhaupt an der Diskussion beteiligen?

Abgesehen davon: wie würde es denn laufen, wenn ich den Nachmittag investieren würde? Ich würde ein Pythonscript präsentieren, das dir das Journal im alten syslog-Format ausgibt, woraufhin du vermutlich „aber aber aber … aber du kannst nich davon ausgehen, dass Python überall verfügbar ist!!k“ antworten würdest. Deine Antipathie dem Neuen gegenüber ist leider unübersehbar, da würde so ein Script genau gar nichts dran ändern. Verlorene Zeit wäre das.

Mich einen Nachmittag hinsetzen um irgendwas zu coden kann ich auch. Und mit etwas Glück macht es dann auch das was es soll. Ich bezweifle aber, dass ich in dieser Zeit einen halbwegs brauchbaren Journal-Parser selbst auf die Beine stellen kann. Und ich bezweifle, dass du es kannst. Wenn das nämlich so einfach wäre, dann bestünde das Problem nicht.
Das hat übrigens nichts mit Antipathie gegen Neues zu tun. Es ist schlicht ein Fakt, dass Systemd trotz aller Vorzüge dem unixoiden Ökosystem als Ganzes einen Bärendienst erweist, weil es als Linuxism an zentraler Stelle spaltet.

Die neue Lösung bietet nunmal Möglichkeiten, die sich ohne die Aufgabe der absoluten Kompatibilität nicht umsetzen ließen. Ich meine, es geht doch nicht um irgend’ne Anwendung, die nun nicht mehr auf ’nem anderen System zum Laufen zu bekommen wäre, sondern um ein Initsystem für Linux, das niemals unter einem anderen System laufen sollte. Warum sollte da die Kompatibilität zu irgendwas anderem gewahrt werden?

Warum reduzierst du denn Systemd schon wieder auf das Init-System? Das ist doch hier gar nicht das Thema. Es geht hier um den Logger Systemd/Journald. Und Logs möchte man im Zweifelsfall systemunabhängig auswerten können.

Gegenfrage: du hast dein nicht mehr bootendes Linuxsystem mit syslog. Du kannst das Dateisystem unter deinem Windows mit dem Treiber (woher hast du den eigentlich in der Situation? Vorher besorgt?

Natürlich habe ich den Dateisystemtreiber vorher besorgt. Ich will ja regulär zwischen beiden OS des Dualboot-Systems Daten austauschen, völlig unabhängig von Havarien.

Warum ginge das mit einem grml-Image nicht?)

Weil das eine Havarielösung ist, genau wie der Umstand, überhaupt einen Rettungsstick parat zu haben. Jetzt kommst du wieder mit "kein Backup, kein Mitleid". Klar, auf den Standpunkt kannst du dich stellen. Aber das hilft dir eben in der konkreten Situation nicht.

Nein, ich bleibe dabei: ich halte deine Szenarien für sehr theoretisch, um nicht zu sagen, völlig praxisfern konstruiert.

Vor ein paar Jahren ist einem Kollegen in seinem Dualboot-Notebook (Linux/Windows) die Linux-Platte gestorben indem sich in kurzer Zeit immer mehr Sektoren verabschiedet haben. Die Windows-Platte war davon unberührt. Weil er natürlich Daten zwischen beiden Systemen austauschen wollte, hatte er auf dem Windows-System einen ext3-Treiber installiert. Damit konnten wir die Logs des Linux-Systems auswerten und kamen so der sterbenden Platte auf die Schliche. Mit Journald (ohne rsyslog-Logs) wäre das nicht gegangen.
Wir hätten uns damals ein Live-Linux besorgen können, aber ich war schon in Situationen wo das mangels Netzzugang nicht ging. "Völlig praxisfern konstruiert" ist hier von mir lediglich, dass ich zwei bereits erlebte Szenarien kombiniert habe. Windows habe ich gegen BSD ersetzt um wenigstens ein unixoides Rettungssystem zu haben und so die Aufgabe zu vereinfachen.

[Lord_Carlos]

Vor ein paar Jahren ist einem Kollegen in seinem Dualboot-Notebook (Linux/Windows) die Linux-Platte gestorben indem sich in kurzer Zeit immer mehr Sektoren verabschiedet haben. Die Windows-Platte war davon unberührt. Weil er natürlich Daten zwischen beiden Systemen austauschen wollte, hatte er auf dem Windows-System einen ext3-Treiber installiert. Damit konnten wir die Logs des Linux-Systems auswerten und kamen so der sterbenden Platte auf die Schliche. Mit Journald (ohne rsyslog-Logs) wäre das nicht gegangen.

Gut das es jetzt WSL gibt :)

Code: Alles auswählen

carlos@mintchip:/mnt/c/Users/carlos$ journalctl --version
systemd 245 (245.4-4ubuntu3.2)
carlos@mintchip:/mnt/c/Users/carlos$ uname -r
4.4.0-19041-Microsoft

Ich sehe es ganz pragmatisch, journalctl hat mehr vorteile als nachteile (fuer mich)
z.B. journalctl /dev/sda sieht man alle logs zu diesem device :) Hilfreich wenn man einen langsam sterbenden Datentraeger hat.

[TomL]

Woher hast du das grml-Image? Im Szenario steht ausdrücklich, dass du keinen Zugriff auf ein anderes Linux als die kaputte Installation hast!

Das ist ein Szenario, mit dem ich auch nicht so recht klar komme. Also, mein Debian kackt ab und bootet nicht mehr.... was tun?

Lösungen:
- Ich habe auf der zweiten Partition ein funktionierendes Windows, damit kann ich aber nicht die Logs lesen... aber ich kann damit auch nicht ins kaputte Debian chrooten. BTW, kann ich mit Windows eigentlich auch problemlos ext4 lesen? Ich lade mir zur Lösung grml runter, packs auf nen Stick, kann dann ext4 mounten, die Logs lesen und auch auch chrooten.

- Ich habe grml auf nem Stick dabei, kein Problem... oder besser, Problem gelöst

- Ich weder weder ein grml noch ein funktionierendes anders Betriebssystem auf dem Rechner verfügbar. Ok, dann kann ich weder chrooten, noch die Logs lesen, noch ein Live-Linux runterladen. In dem Fall ist es allerdings auch völlig egal, ob das Binary-Logs sind. Ich entspanne mich beim Lesen eines Buches.

Stell ich mir das jetzt zu einfach vor?

[DeletedUserReAsG]

Nichts leichter als das:
Ein langsam sterbender Datenträger.

Dann bekomme ich das System von einem Fremdsystem aus auch nicht wieder flott. Insofern: wie soll’s mir da helfen, von einem Fremdsystem aus ein hübsch formatiertes Log zu sehen? Die Fehlermeldungen sprängen mir auch in der ungefilterten Ausgabe von strings direkt ins Auge. Außerdem wäre bei Anzeichen eines sterbenden Datenträgers mein erster Gedanke sicher nicht, von einem Fremdsystem aus mit Treibern zweifelhafter Qualität auf das labile Dateisystem zuzugreifen, sondern mein Livesystem zu booten und vorsichtig zu gucken, was da los sein mag.

Weil du also auf alles vorbereitet bist, änderst du einfach die Aufgabenstellung
[…]
Um darzulegen, dass du die gestellte Aufgabe lösen kannst und nicht irgendeine andere, die du dir selbst ausgedacht hast. Warum sonst solltest du dich überhaupt an der Diskussion beteiligen?

Ach, ist ’ne theoretische Diskussion? Dann bin ich raus – ich dachte, es ginge um reale Argumente, nicht hypothetische Aufgabenstellungen. Ich dachte halt, es gäbe reale, nachvollziehbare Gründe für deine Ablehnung der Sachen. Offensichtlich geht’s dir aber nur um die Ablehnung um der Ablehnung willen. Kann man machen, aber da beteilige ich mich dann auch nicht weiter dran. Wozu soll sowas auch gut sein?

Mich einen Nachmittag hinsetzen um irgendwas zu coden kann ich auch. Und mit etwas Glück macht es dann auch das was es soll. Ich bezweifle aber, dass ich in dieser Zeit einen halbwegs brauchbaren Journal-Parser selbst auf die Beine stellen kann. Und ich bezweifle, dass du es kannst. Wenn das nämlich so einfach wäre, dann bestünde das Problem nicht.

Was meinst du, mit dieser Provokation zu bezwecken? Ich weiß, was ich kann. Und ich habe ’nen brauchbaren Überblick über die Struktur des Journals. Und ich denke, ich könnte beides zusammenführen, wenn ich einen Sinn darin sehen würde. Und nein, dich zu beeindrucken, erscheint mir nicht als sinnvolles Ziel – ich kenne dich ja nicht mal. Letztlich wäre das ’ne Verschwendung von Ressourcen – weder würd’s dich umstimmen, noch würde es irgendjemandem nutzen – denn wer Linux fährt, greift in dem seltenen Fall, dass es nicht mehr bootet, auch einfach von ’nem Linux-Livesystem o.Ä. drauf zu.

Und dein Linuxism … du erwartest also wirklich bedingungslose Kompatibilität zu Fremdsystemen, der zugunsten alle linuxspezifischen Möglichkeiten brach liegengelassen werden sollen? Für die 0,0x% der Linuxuser (also 0,00x% der Desktopuser insgesamt), die überhaupt ein Setup fahren, bei dem das für sie einen Vorteil bringen könnte? Wirklich?

Für so engstirnig und egoistisch hatte ich dich eigentlich nicht gehalten …

Es geht hier um den Logger Systemd/Journald. Und Logs möchte man im Zweifelsfall systemunabhängig auswerten können.

s/man/ich/ – denn du bist einer der sehr wenigen Leute, die überhaupt auf so eine Idee kommen. Andere haben nicht mal andere Systeme, stattdessen aber ein Livesystem auf irgend’nem 2€-USB-Stick, oder die Möglichkeit, eines zu erstellen.

Natürlich habe ich den Dateisystemtreiber vorher besorgt. Ich will ja regulär zwischen beiden OS des Dualboot-Systems Daten austauschen, völlig unabhängig von Havarien.

… auf die Idee bin ich selbst zu Dualboot-Zeiten nicht gekommen. Was sollte ich unter Windows mit Daten anfangen, die unter Linux lagen? Und für die wenigen Fälle, in denen ein Austausch nötig war, hat’s gereicht, die Daten von Linux aus auf die Windowsplatte zu schieben, oder von dort zu holen.

Vor ein paar Jahren ist einem Kollegen in seinem Dualboot-Notebook (Linux/Windows) die Linux-Platte gestorben indem sich in kurzer Zeit immer mehr Sektoren verabschiedet haben. Die Windows-Platte war davon unberührt. Weil er natürlich Daten zwischen beiden Systemen austauschen wollte, hatte er auf dem Windows-System einen ext3-Treiber installiert. Damit konnten wir die Logs des Linux-Systems auswerten und kamen so der sterbenden Platte auf die Schliche.

Gut. Und heute habe ich ein mit dm_crypt über LVM gesichertes System, irgendwo darunter vielleicht noch ein BTRFS. Erkläre mir bitte mit einfachen Worten, wie syslogd da gegenüber journald irgendwelche Vorteile für den Zugriff unter Windows haben würde. Außerdem stellt sich mir die Frage: wenn man ein System von einem HDD mit solchem Fehlerbild bootet, kann man die einschlägigen Fehlermeldungen, mit denen das Booten misslingt, eigentlich gar nicht übersehen – welchen erweiterten Erkenntnisgewinn hattet ihr genau davon, das Log von Windows aus einsehen zu können?

[hikaru]

Ich sehe es ganz pragmatisch, journalctl hat mehr vorteile als nachteile (fuer mich)
z.B. journalctl /dev/sda sieht man alle logs zu diesem device Hilfreich wenn man einen langsam sterbenden Datentraeger hat.

Sehe ich auch so. Aber es setzt eben voraus, das journalctl überhaupt noch funktioniert. Und diese Vorausetzung sehe ich als eklatanten Designfehler.

- Ich habe auf der zweiten Partition ein funktionierendes Windows, damit kann ich aber nicht die Logs lesen... aber ich kann damit auch nicht ins kaputte Debian chrooten.

Plaintext-Logs kann man von Windows aus (sinnvoll) lesen.

BTW, kann ich mit Windows eigentlich auch problemlos ext4 lesen?

Soweit ich weiß kann ext2fs inzwischen auch ext4. Ich habe mich damit aber lange nicht mehr beschäftigt. Als ich es noch genutzt habe konnte es stabil ext2 lesen und schreiben. Ext3 galt als "so gut wie stabil". Man konnte damit sowohl rw als auch ro mounten.

Ich lade mir zur Lösung grml runter, packs auf nen Stick, kann dann ext4 mounten, die Logs lesen und auch auch chrooten.

Sofern du Internet hast.

- Ich weder weder ein grml noch ein funktionierendes anders Betriebssystem auf dem Rechner verfügbar. Ok, dann kann ich weder chrooten, noch die Logs lesen, noch ein Live-Linux runterladen. In dem Fall ist es allerdings auch völlig egal, ob das Binary-Logs sind. Ich entspanne mich beim Lesen eines Buches.

Wenn es ein Produktivsystem ist auf das man angewiesen ist, dann ist das mit der Entspannung nicht so einfach. Wir haben damals bei meinem Kollegen nach Auslesen der Logs eine neue HDD besorgt und ich habe seitdem immer einen Rettungsstick dabei. Aber schlauer ist man immer erst hinterher.

mein Livesystem
[..]
Für so engstirnig und egoistisch hatte ich dich eigentlich nicht gehalten …
[..]
Dann bin ich raus

Danke!

[heinz]

Ich kann hikaru sehr gut verstehen.

Ich wuerde es z.B. sehr begruessen, wenn in absehbarer Zeit Debian wieder von systemd komplett abstand nehmen wuerde. Was leider wohl nicht geschehen wird.

Es ist viel zu umfangreich.
Es will "alles" koennen und sich um "alles" kuemmern aber schafft es halt nicht so recht.
Auch die Abkehr von (mit jedem Text-betrachter/-editor) lesbaren Log-Dateien empfinde ich als eine nutzlose Katastrophe.

M.M.n. ist Unix/Linux so erfolgreich geworden weil auf es aus vielen kleinen Tools besteht, die alle ihre Arbeit perfekt koennen und auch sehr ausgereift/fehlerbefreit sind.
Aus denen kann man wirklich alles Bauen, - wie in Lego...
Dieses erfolgreiche Konzept sollte man unbedingt beibehalten sonst endet man bei riesigen, unwartbaren
"Code-Monstern".
Mag sein, das ein solches Konstrukt aus vielen kleinen Tools manchmal etwas langsamer laeuft.
Aber die Flexibilitaet und wartbarkeit finde ich unuebertroffen. (Auch wenn das manche anders sehen...)

Ich habe manchmal das Gefuehl, da will sich nur jemand mit einem Projekt verewigen.
Wenn man es nicht mehr so einfach weglassen kann da vieles davon abhaengt, um so besser...
Einerseits verstaendlich, andererseits eine Katastrophe...

Klar, die Welt aendert sich und Dinge werden weiterentwickelt...
Aber man muss gutes/gut funktionierendes nicht unbedingt nur ersetzen, um des "zu erneuerns" willen.

Leider habe ich das auch schon bei einigen anderen Projekten "gesehen".
Vielleicht werde ich ja auch zu alt fuer sowas und unflexieble Code-Monster/Vorgehensweisen sind gerade super inn...

Das alles ist natuerlich nur meine eigene Meinung und ich moechte auch nicht, das diese Diskussion unnoetig verlaengert wird.
Ich sah mich nur ausser Stande, hier nicht meinen Senf dazu geben zu muessen... Sorry...


Gruß,
heinz

[Lord_Carlos]

Es will "alles" koennen und sich um "alles" kuemmern aber schafft es halt nicht so recht.

Um was will sich systemd kuemmern und schafft es nicht?

[DeletedUserReAsG]

Sorry, bei dieser Provokation muss noch der richtige Bezug wiederhergestellt werden:

mein Livesystem
[..]
Für so engstirnig und egoistisch hatte ich dich eigentlich nicht gehalten …
[..]

Ein Livesystem kann jeder haben. Das kostet nix, und es ist nicht egoistisch, wenn ich eines habe, und daher journald vollkommen okay finde, weil’s mir auch von da aus das Hantieren mit den Logs erheblich erleichtert. Einer der Wenigen zu sein, die von ’nem BSD aus auf das Log zugreifen wollen, und alleine aus dem Grund heraus zu verlangen, dass alle anderen auf systemspezifische Vorteile verzichten müssen, damit er im Bedarfsfall kein Livesystem starten muss, das ist nunmal egoistisch und engstirnig.

Dann bin ich raus

Danke!

Bitte. Vorausgesetzt, du zitierst nicht wieder ohne Kontext Dinge zusammen, die nicht zusammen geschrieben wurden.

[heinz]

Es will "alles" koennen und sich um "alles" kuemmern aber schafft es halt nicht so recht.

Um was will sich systemd kuemmern und schafft es nicht?

Ich schrieb nicht "schafft es nicht" sondern "schafft es nicht so recht" also sowas wie "war stets bemueht".
(Das ist rein aus meiner Sicht und nicht dazu gedacht hier wieder eine neue Disskussion zu starten...)

Durchsuch allein hier das Forum nach Problemen die Nutzer mit systemd haben/hatten und Du wirst genug Beispiele finden...
Manchmal liegt es vlt. auch garnicht direkt an systemd sondern an der Art, wie man es zu bedienen hat.
Das hat sich halt einer/eine kleine Gruppe so ausgedacht und so muss man es auch gefaelligst machen.

Was mich am meisten an systemd stoert ist, das man es nicht einfach weglassen/duch SysV oder "sonswas" ersetzen kann.
Man muss mittlerweile grosse "Klimmzuege" machen um das zu erreichen.
Und in ein paar Jahren wird es wohl nicht mehr moeglich sein, da immer mehr Programme sich davon abhaengig machen.

Eine der Staerken von debian war doch, das man sich sein System genau so konfigurieren konnte wie man wollte.
Alles war irgendwie "Optional", man konnte sich entscheiden was man gerne haette.
Warum wird das jetzt so erschwert/unmoeglich gemacht?

Steckt die Manpower in devuan, die debian davon abhaelt systemd optional zu betreiben?

Auch sehr Nett... Gabs hier wohl schon...
viewtopic.php?f=15&t=170244&hilit=erfahrungen+devuan

[ralli]

Irgendwie ist es mir egal, ich möchte mein System produktiv nutzen und fertig. Das ich als User gewungen werde, systemd zu nutzen, empfand ich schon immer als kontraproduktiv. Deshalb schrieb ich mal provokativ "Opensource ist eine Illusion". Freiheit des Nutzers würde bedeuten, das er sich selbstbestimmt für systemd oder dem Vorgänger entscheidet. Ansonsten geht es mir am A..... vorbei, mein Workflow ist nicht so anspruchsvoll, und surfen, mailen, Audio und Video, schreiben von Essays, alles das tut es ja. Also bin ich zufrieden. Linux ist längst kommerzialisiert und einige wenige bestimmen, wo es lang zu gehen hat. Na ja, Debian kommt zumindest der Vorstellung eines puren freien Systems am nächsten. Und ist zudem rocksolide.... Was will ich mehr ....?

Gruß ralli

[Meillo]

M.M.n. ist Unix/Linux so erfolgreich geworden weil auf es aus vielen kleinen Tools besteht, die alle ihre Arbeit perfekt koennen und auch sehr ausgereift/fehlerbefreit sind.
Aus denen kann man wirklich alles Bauen, - wie in Lego...
Dieses erfolgreiche Konzept sollte man unbedingt beibehalten sonst endet man bei riesigen, unwartbaren
"Code-Monstern".

Ich denke, dass Systemd & Co. in manchen Situationen durchaus eine gute Wahl sein kann, aber nicht in allen. Ich denke, dass kein einziges System fuer alle Situatioen die beste Wahl sein kann. Darum finde ich es wichtig, dass man die Moeglichkeit hat, komponentenweise auszutauschen. Dieses Konzept ist schon immer sehr tief in Unix verankert gewesen. Das ist IMO ein grosser Erfolgsfaktor. Darum ist es auch nach 50 Jahren (!) noch aktuell und zeitgemaess.

Da stimme ich heinz also zu. Man muss allerdings auch sehen, dass Unix (im Gegensatz zu heinz' Darstellung) eigentlich nie Perfektion geboten hat (abgesehen vom System-Call-Interface vielleicht). Unix war stets der Vertreter von ``worse is better''. Unix war erfolglich weil es pragmatisch war, weil es offen war, weil es sich veraendert hat, angepasst hat, weil viele Personen ihre Einfluesse eingebracht haben, weil es flexibel war und verschiedene Formen annehmen konnte. Systemd abzulehnen oder sich an System-V-Init zu klammern entspricht also eher nicht dem Unix-Denken. Offenheit und Ausprobieren von Neuem entspricht ihm viel mehr. Ebenso entsprechen aber auch singulaere Loesungen nicht dem Unix-Denken, sondern es war immer die Austauschbarkeit, die Offenheit fuer Alternativen, die Unix ausgemacht hat.

Ich habe also kein Problem damit, dass es Systemd gibt. Es sollte in den Szenarien eingesetzt werden, in denen es Sinn macht. Es sollte aber eine gleichwertige Wahl fuer alternative Init-Systeme vorhanden sein, fuer diejenigen Szenarien, in denen sie mehr Sinn machen. Jede Spezialisierung in Form einer Festlegung auf nur einen Weg ist ein Einschwenken in einen Weg der frueher oder spaeter enden wird. Natuerlich wirkt es kurzfristig gesehen einfacher und besser die Vielfalt zu kappen, aber langfristig bringt es einen auf's Abstellgleis. Man muss halt auch den Wert davon erkennen, dass Unix schon 50 Jahre lang lebt. Nur wenn man mit einem Zeithorizont von mehr als fuenf Jahren auf die Systeme blickt, wird man auch bereit sein, manche Investitionen zu taetigen. Die Schaeden von vernachlaessigter Infrastruktur (und dazu zaehle ich die Offenheit fuer Vielfalt) merkt man laengere Zeit gar nicht. Man profitiert nur von den eingesparten Kosten. Erst spaeter holt es einen ein, und dann steht man vor einem unfassbar grossen Haufen aufgelaufener Kosten, der nicht mehr bewaeltigbar erscheint (enthaelt er doch die eingesparte Pflege vieler Jahre), mit der Folge, dass man nur noch eine Option sieht: wegwerfen und neu beginnen. Dieses Handeln und Denken stoert mich sehr, diese Wegwerfmentalitaet als Folge kurzfristiger und einperspektivischer Weltsicht. Qualitaetsaspekte, v.a. strukturelle Qualitaet, sind von grosster Wichtigkeit, denn sie wirkt langfristig und grundlegend. Allerdings ist sie auch am wenigsten sichtbar und kaum messbar. Das ist der Grund weshalb die Diskussionen so schnell ``philosophisch'' werden -- es ist schwer alternative Sichten auf die Welt weiterzugeben. Wer so nicht sehen will wird auch nicht so sehen. Da hilft keine Argumentation.