Login
Newsletter
Werbung

Thema: Debian diskutiert weiter über Systemd

11 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
2
Von jhohm am Do, 6. Februar 2020 um 12:34 #

----------------Zitat-----------------------

Die Diskussion auf der Debian-Liste zeigt, dass die Kritiker die Möglichkeiten von Journald gar nicht kannten. So fürchteten einige, dass seit Jahren eingespielte Abläufe nicht mehr funktionieren würden. Ein anderer Entwickler bedauerte, dass künftig nicht mehr alle auf E-Mail bezogenen Logs unter dem Pfad /var/log/mail zu finden seien.

------------------Zitat-Ende---------------

Typisch! Erstmal meckern und motzen, aber NULL Ahnung haben.
Ein echtes Trauerspiel....

  • 1
    Von comrad am Do, 6. Februar 2020 um 14:07 #

    das heisst doch nicht NULL, sondern man benutzt jetzt nullptr

    • 1
      Von Unerkannt am Do, 6. Februar 2020 um 17:23 #

      In C ist es immer noch das NULL-Makro.

      • 0
        Von George99 am Do, 6. Februar 2020 um 19:48 #

        Oder noch einfacher: 0

        Und Abfrage dann mit if (ptr) {...} btw. if (!ptr) {...}

        Bin kein Freund dieser geschwätzigen Programmierstile.

        • 0
          Von Unerkannt am Do, 6. Februar 2020 um 21:12 #

          Oder noch einfacher: 0
          Ich denke das ist nicht richtig. 0 ist eine nicht ganz definierte Integerkonstante (vom Typ her). Sie hat jedenfalls einen Integertyp (keinen Pointer-Typ) und NULL hat definitiv einen Pointer-Typ.

          • 0
            Von Tamaskan am Fr, 7. Februar 2020 um 09:39 #

            In C ist NULL als ((void*)0) definiert, in C++ als 0. In beiden Fällen ist jedoch nicht die numerische Null gemeint, sondern die Adresse 0, die keine gültige Adresse ist. Es kann aber passieren, dass NULL implizit zur numerischen Null konvertiert wird, was man in der Regel ja nicht will.

            Ab C++11 gibt es nullptr vom Typ std::nullptr_t. Dieser lässt sich implizit nur zu bool konvertieren, wodurch man Nullpointer weiterhin in Bedingungen verwendet kann, man kann aber nicht mehr versehentlich einen Nullpointer mit einem Integer verrechnen und ähnliches.

          0
          Von ah am Fr, 7. Februar 2020 um 18:20 #

          > if (ptr) {...} btw. if (!ptr) {...}

          Schlechter Programmierstil. Zum Glück gibt es heute Sprachen, die eine echte boolesche Bedingung beim if erzwingen. Fehleranfällige Sprachen wie C sterben hoffentlich bald aus...

    0
    Von bj am Mo, 10. Februar 2020 um 12:52 #

    Tut mir leid, aber ich kannte diese Möglichkeit von 'systemd' bereits. Trotzdem bin ich nicht damit einverstanden, dass diese eierlegende Wollmilchsau sich nach und nach im gesamten System ausbreitet.

    Habt eigentlich irgendjemand einmal über das einfache Grundprinzip nachgedacht, das ein System (insbesondere ein Programm) mit zunehmender Komplexität immer anfälliger für Fehler (und damit auch für Angriffe) wird.

    Meiner bescheidenen Meinung nach ist der einzige Grund, warum ein gewisser Debian-Entwickler den 'rsyslog' ab liebsten wegwerfen würde, ist der, dass er sich weniger Arbeit machen möchte ... was ja noch irgendwo einzusehen ist. Wenn allerdings der 'rsyslog' von diesem Entwickler nun gar nicht direkt betreut wird, dann könnten durchaus noch andere Gründe dahinter stehen (wie z.B. persönliche Streitigkeiten), die als Grund für eine solche Entscheidung überhaupt nicht akzeptiert werden dürfen.

    Na gut ... man muss ja 'rsyslog' nicht zwangsweise einsetzen. Für mich sieht das aber so aus, wie bei der Diskussion um das Init-System selbst, nämlich den Versuch, den 'rsyslog' vollständig aus dem System zu werfen - eine Entscheidung die ich aus dem oben genannten Grund als fatal ansehen würde, und die mich dazu bewegen könnte, zukünftig auf Debian zu verzichten. Das wäre allerdings wirklich schade, weil ich mit Debian eigentlich bisher sehr gute Erfahrungen gemacht hatte.

    • 0
      Von klopskind am Mo, 10. Februar 2020 um 21:36 #

      Trotzdem bin ich nicht damit einverstanden, dass diese eierlegende Wollmilchsau sich nach und nach im gesamten System ausbreitet.
      Ich kann diese Haltung nachvollziehen, allerdings muss ich an dieser Stelle sagen, dass systemd-journald zuvor in Debian ohnehin schon parallel zu rsyslogd lief. Diese Entscheidung würde nicht zu einer erweiternden Ausbreitung systemds führen.

      Habt eigentlich irgendjemand einmal über das einfache Grundprinzip nachgedacht, das ein System (insbesondere ein Programm) mit zunehmender Komplexität immer anfälliger für Fehler (und damit auch für Angriffe) wird.
      Da haben sicherlich schon viele darüber nachgedacht. Offenbar werden seitens der Entwickler einige Funktionen von systemd benötigt. Vom Konzept her ist es ja auch nichts neues. Lennart hat sich von launchd und SMF inspirieren lassen. Also scheinen zuvor schon andere namhafte Plattformentwickler die Wichtigkeit dieser Funktionen eingesehen zu haben. Und die Funktionen werden teils rege genutzt. In vielen Fällen auch aus gutem Grund und in Ermangelung an funkionellen Alternativen.

      Nicht in jedem Anwendungsfall sind diese Funktionen nötig. In einige Szenarien kommt man SysVinit gut aus. Allerdings hat sich das Aufgaben- und Anforderungsfeld über die Jahrzente derart geändert, dass sich einige Dinge nicht mehr sauber auf die Konzepte von SysVinit abbilden lassen. Es mussten neuartige Konzepte her, die die bisherigen Anwendungsfälle so gut es geht unterstützen oder abbilden.

      Natürlich bedarf dies einer höheren Komplexität innerhalb systemds. Andernfalls wäre SysVinit nicht gescheit implementiert gewesen. Offenbar waren aber die Vorteile, nämlich die Minimierung der Schwierigkeiten in den darüberliegenden Schichten derart enorm, dass dies die Nachteile wett macht(e). Ein Vorteil ist auch, dass die Distributoren nun viel stärker kollaborieren als zuvor, denn vor systemd hat jeder sein eigenes Ding gedreht. Das frisst auch unnötige Entwicklerressourcen - nicht nur an init selbst, sondern eben auch in den darüberliegenden Schichten, wegen unnötiger Fragmentierung.

      Meiner bescheidenen Meinung nach ist der einzige Grund, warum ein gewisser Debian-Entwickler den 'rsyslog' ab liebsten wegwerfen würde, ist der, dass er sich weniger Arbeit machen möchte ... was ja noch irgendwo einzusehen ist. Wenn allerdings der 'rsyslog' von diesem Entwickler nun gar nicht direkt betreut wird, dann [...]
      Das systemd-journald wurde seit systemd in Debian Standard ist, standardmäßig betrieben, wie es für alle mir bekannten systemd-Distributionen üblich (oder sogar nötig?) ist. Nicht nur in Debian wurde für die Wahrung der Kompatibilität weiterhin rsyslogd nebenher betrieben, systemd-journald leitete die Logs nur weiter. Für diese Aufgabe war systemd-journald u.A konzipiert. Weitere Gründe waren meinen Vermutungen nach einerseits, dass systemd-journald noch nicht die gewünschte Reife hatte bzw. zentrale Features noch fehlten, und andererseits ein Art "Salamitaktik" bei der Einführung in Debian. Die Binärlogs waren (und sind teils noch) sehr großte Kritikpunkte. Die Handhabung etwaiger Korruptionen der Logs wurde verbessert.

      Ergo liefen (und laufen noch) die ganze Zeit zwei Log-Dienste parallel, was unsinnig ist. Wenn jetzt systemd-journald in Debian Standard wird, heißt das eigentlich nur, dass eine Einstellung umgebogen wird und rsyslogd (eventuell, ist noch in Planung/Verhandlung) optional statt essentiell wird, womit rsyslogd standardmäßig nicht mehr installiert würde, aber nach einer Installation so läuft wie zuvor auch. Und das wird langfristig auch so bleiben. Ich sehe keinen guten Grund, warum systemd-journald die Hoheit auf Logs beanspruchen sollte, rein technisch und politisch nicht. Das Risiko wäre viel zu groß.

      systemd-journald wurde in Debian die ganze Zeit schon betrieben und musste daher auch entsprechend gepflegt werden. Es geht darum, dass sich das Projekt als Gesamtheit weniger Arbeit macht, und der Großteil der Installationen weniger Ballast mitschleppt und Ressourcen fürs doppelte Logging verschwendet.
      Ihr Argument finde ich demnach äußerst schwach.

      Na gut ... man muss ja 'rsyslog' nicht zwangsweise einsetzen. Für mich sieht das aber so aus, wie bei der Diskussion um das Init-System selbst, nämlich den Versuch, den 'rsyslog' vollständig aus dem System zu werfen [...]
      Das glaube ich nicht. Die Befürworter von der Umstellung im Artikel geht es um den Regelfall. Sie nehmen wohlwollend zur Kenntnis, dass es sehr gute Gründe gibt, anderer Log-Dienste als systemd-journald einzusetzen.
      Darüber hinaus haben sie allein nicht darüber zu entscheiden, ob oder wann rsyslogd aus Debian hinaus fliegt. Das liegt allein an den Maintainern und deren Pflege des Pakets. Ich kann nicht erkennen, dass es schwieriger werden sollte, rsyslogd unter Debian zum Laufen zu bringen. Das ist jetzt nicht wie ein udev oder logind, das zurechtgebogen werden müsste.
      Außerdem ist SysVinit nach wie vor in Debian enthalten, siehe hier.

      Auch diese Befürchtungen bzw. das damit aufgestellte Argument wäre damit entkräftet.

      0
      Von Verfluchtnochmal_5987108 am Di, 11. Februar 2020 um 19:27 #

      Du Kasperle journald ist die ganze Zeit da, es geht nur darum dass als default nicht auch noch parallel rsyslog laufen muß und derjenige der es haben will kann das auch weiterhin

      Dass die Debilianer nach so vielen Jahren immer noch Diskussionen ohne Sinn und Verstand führen lässt tief blicken

Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten
Werbung