1. Foren
  2. Sonstiges
  3. Bolzplatz

Re: Systemd statt Consolekit

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. Re: Systemd statt Consolekit

    Autor: Hello_World 28.02.12 - 21:10

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Was ist denn daran kompliziert, sich dem Problem anzunähern indem ich ein
    > paar print's platziere?
    Dass es total überflüssig ist vielleicht?! Init-Scripte machen zu 99% immer dasselbe: einen Daemon starten, die PID in ein PID-File schreiben, vielleicht ein paar ulimits setzen, vielleicht ein paar Umgebungsvariablen setzen, Signale an laufende Daemons senden etc.. Es ist wesentlich weniger fehleranfällig, das einmal korrekt im init-System zu implementieren, statt die gleichen Sachen immer und immer wieder in irgendwelchen init-Scripten zu machen.

    > Wie lange laufen die Systeme bereits, viele Bugs
    > hast bereits miterlebt? Ich kann mir nicht vorstellen das Debugging im
    > Kernel und Systemd viel angenehmer ist, wenn mal etwas nicht so
    > funktioniert wie angenommen.
    Wieso sollte ich systemd oder den Kernel debuggen? Kernelbugs beißen Dich auch mit sysvinit, und dass ein Bug in systemd auftritt ist kein bisschen wahrscheinlicher als Bugs in sysvinit und den riesigen Haufen Tools, die man von init-Scripten aus verwendet: bash, awk, grep, sed, cap, cut, cat, ps und weiß der Geier was noch.

    > Und die Kommentare im Quellcode erwecken auf
    > mich nicht den Eindruck, dass man fehlerfreie Software ausliefern will.
    Das ist der reine FUD. Wenn Du einen Bug gefunden hast, dann schreib das, und wenn nicht, dann hör auf zu trollen.

    > Ich finde gerade nicht die E-Mail von Poettering wo steht was für Kernel
    > Feature Systemd vorraussetzt, aber wenige waren das. Müsste irgendwo in der
    > Korrespondenz von Poettering an Gnome sein.
    Offensichtlich bist Du nicht in der Lage, zwischen einem abstrakten Konzept und einer konkreten Implementierung zu unterscheiden. Armes Würstchen...

  2. Re: Systemd statt Consolekit

    Autor: bstea 28.02.12 - 23:28

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > bstea schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Was ist denn daran kompliziert, sich dem Problem anzunähern indem ich
    > ein
    > > paar print's platziere?
    > Dass es total überflüssig ist vielleicht?! Init-Scripte machen zu 99% immer
    > dasselbe: einen Daemon starten, die PID in ein PID-File schreiben,
    > vielleicht ein paar ulimits setzen, vielleicht ein paar Umgebungsvariablen
    > setzen, Signale an laufende Daemons senden etc.. Es ist wesentlich weniger
    > fehleranfällig, das einmal korrekt im init-System zu implementieren, statt
    > die gleichen Sachen immer und immer wieder in irgendwelchen init-Scripten
    > zu machen.
    >
    Genau und deshalb wird funktionierende durch experimentielles ersetzet. Logisch das daduch die Fehlerrate runtergeht. Sag mal, lies du eigentlich den Quatsch den du von dir gibst?
    > > Wie lange laufen die Systeme bereits, viele Bugs
    > > hast bereits miterlebt? Ich kann mir nicht vorstellen das Debugging im
    > > Kernel und Systemd viel angenehmer ist, wenn mal etwas nicht so
    > > funktioniert wie angenommen.
    > Wieso sollte ich systemd oder den Kernel debuggen? Kernelbugs beißen Dich
    > auch mit sysvinit, und dass ein Bug in systemd auftritt ist kein bisschen
    > wahrscheinlicher als Bugs in sysvinit und den riesigen Haufen Tools, die
    > man von init-Scripten aus verwendet: bash, awk, grep, sed, cap, cut, cat,
    > ps und weiß der Geier was noch.
    >
    WEIL SYSTEMD EINEN FETTEN HAUFEN VON KERNELFEATURES NUTZT. MIR IST NOCH KEIN BUG IN DEN INIT SCRIPTEN UND DARUNTER UNTERGEKOMMEN.
    > > Und die Kommentare im Quellcode erwecken auf
    > > mich nicht den Eindruck, dass man fehlerfreie Software ausliefern will.
    > Das ist der reine FUD. Wenn Du einen Bug gefunden hast, dann schreib das,
    > und wenn nicht, dann hör auf zu trollen.
    >
    Der Bug(bspw. " separate-usr-is-broken") ist doch bereits im Quellcode funktioniert nicht, aber trolle nur weiter. Ist übrigens nicht der einzige.
    > > Ich finde gerade nicht die E-Mail von Poettering wo steht was für Kernel
    > > Feature Systemd vorraussetzt, aber wenige waren das. Müsste irgendwo in
    > der
    > > Korrespondenz von Poettering an Gnome sein.
    > Offensichtlich bist Du nicht in der Lage, zwischen einem abstrakten Konzept
    > und einer konkreten Implementierung zu unterscheiden. Armes Würstchen...

    Oja ein Interface wovon es stets nur eine Implementierung gibt, ganz toll.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  3. Re: Systemd statt Consolekit

    Autor: Hello_World 29.02.12 - 03:00

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Genau und deshalb wird funktionierende durch experimentielles ersetzet.
    Es ist immer so, dass neue Lösungen zunächst einmal weniger ausgereift sind als bestehendes. Soll man deswegen jetzt nie wieder etwas neues schreiben? Langfristig erhöht sich durch systemd die Robustheit und Effizienz des Bootvorgangs, weil eben für jeden Daemon der gleiche ausgereifte und debuggte Code verwendet wird.

    > Logisch das daduch die Fehlerrate runtergeht. Sag mal, lies du eigentlich
    > den Quatsch den du von dir gibst?
    Ich kann hier nur meine eigenen Erfahrungen wiedergeben, und die besagen, dass systemd mittlerweile unter verschiedenen Distributionen ausgezeichnet funktioniert, darunter Fedora 16, openSUSE 12.1 und Debian Sid.

    > WEIL SYSTEMD EINEN FETTEN HAUFEN VON KERNELFEATURES NUTZT.
    Ach. Also soll man jetzt auf einmal existierende und funktionierende Kernelfeatures nicht nutzen, weil sie vielleicht einen Bug enthalten könnten? Also eine so bescheuerte Argumentation ist mir wirklich schon lange nicht mehr untergekommen.

    Fakt ist: ohne die Nutzung Linux-spezifischer Kernelfeatures (cgroups) ist es nicht einmal möglich, Dienste zuverlässig zu beenden. Nehmen wir Apache. Angenommen, man betreibt einen Shared-Hosting-Server mit CGI/Perl, und ein Nutzer double-forked in seinem CGI-Script, d. h. der Vater des CGI-Scripts ist jetzt init und nicht mehr Apache. Wie soll ein init-Script jemals erkennen, dass dieses CGI-Script von Apache gestartet wurde und daher beim herunterfahren des Apache-Dienstes auch beendet werden muss?
    Systemd verwendet diese Kernelfeatures nicht, damit es so schön unportabel ist, sondern weil es schlicht nötig und sinnvoll ist, um die gewünschten Features zu implementieren.

    > MIR IST NOCH
    > KEIN BUG IN DEN INIT SCRIPTEN UND DARUNTER UNTERGEKOMMEN.
    Ja, weil irgendjemand bei Deiner Distri Zeit und Arbeit investiert, um sie zu debuggen. Eine systemd-Unit ist mit Sicherheit einfacher zu schreiben, und einen Bug in systemd diesbezüglich habe ich auch noch nie gesehen. Du?

    > Der Bug(bspw. " separate-usr-is-broken") ist doch bereits im Quellcode
    > funktioniert nicht, aber trolle nur weiter.
    Du beziehst Dich wohl auf das hier:
    http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
    Das hat exakt gar nichts mit systemd zu tun. Zitat:
    "systemd works fine with /usr on a separate file system that is not pre-mounted at boot. "
    Und übrigens auch das hier: "The message is merely a warning. You can choose to ignore it."

    > Oja ein Interface wovon es stets nur eine Implementierung gibt, ganz toll.
    Es gibt nur eine Implementierung, weil die Konkurrenz sich (bisher) dagegen entschieden hat, das Interface zu implementieren. Das ist aber kein Problem in systemd, da das Interface für socket activation so ziemlich die simpelste Möglichkeit darstellt.



    1 mal bearbeitet, zuletzt am 29.02.12 03:02 durch Hello_World.

  4. Also irgendwie will er nicht

    Autor: ChilliConCarne 29.02.12 - 08:02

    Und sein aggressiver Ton lässt auch nicht darauf schließen, dass er sich die nachvollziehbaren Argumente deinerseits wirklich mal in Ruhe durch den Kopf gehen lässt.

  5. Re: Also irgendwie will er nicht

    Autor: bstea 29.02.12 - 08:23

    Was ist daran aggressiv? Störend ist nur dein Geblubber!

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  6. Re: Systemd statt Consolekit

    Autor: bstea 29.02.12 - 08:47

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > bstea schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Genau und deshalb wird funktionierende durch experimentielles ersetzet.
    > Es ist immer so, dass neue Lösungen zunächst einmal weniger ausgereift sind
    > als bestehendes. Soll man deswegen jetzt nie wieder etwas neues schreiben?
    > Langfristig erhöht sich durch systemd die Robustheit und Effizienz des
    > Bootvorgangs, weil eben für jeden Daemon der gleiche ausgereifte und
    > debuggte Code verwendet wird.
    >
    Die "Ausgereiftheit" wird erst die Praxis noch zeigen müssen. Und wie du schon sprachst, Shell Skripte ähneln sich stark und damit sie wieder an Anfang. Man ersetzt was simples ausgereiftes gegen komplexen C Code, der nach deiner Meinung weniger komplex ist als Shell Code.
    > > Logisch das daduch die Fehlerrate runtergeht. Sag mal, lies du
    > eigentlich
    > > den Quatsch den du von dir gibst?
    > Ich kann hier nur meine eigenen Erfahrungen wiedergeben, und die besagen,
    > dass systemd mittlerweile unter verschiedenen Distributionen ausgezeichnet
    > funktioniert, darunter Fedora 16, openSUSE 12.1 und Debian Sid.
    >
    > > WEIL SYSTEMD EINEN FETTEN HAUFEN VON KERNELFEATURES NUTZT.
    > Ach. Also soll man jetzt auf einmal existierende und funktionierende
    > Kernelfeatures nicht nutzen, weil sie vielleicht einen Bug enthalten
    > könnten? Also eine so bescheuerte Argumentation ist mir wirklich schon
    > lange nicht mehr untergekommen.
    >
    Nö, man beschränkt sich auf die nötigen und sichert ab, dass die wenigstens eine Weile Bestand haben.
    > Fakt ist: ohne die Nutzung Linux-spezifischer Kernelfeatures (cgroups) ist
    > es nicht einmal möglich, Dienste zuverlässig zu beenden. Nehmen wir Apache.
    > Angenommen, man betreibt einen Shared-Hosting-Server mit CGI/Perl, und ein
    > Nutzer double-forked in seinem CGI-Script, d. h. der Vater des CGI-Scripts
    > ist jetzt init und nicht mehr Apache. Wie soll ein init-Script jemals
    > erkennen, dass dieses CGI-Script von Apache gestartet wurde und daher beim
    > herunterfahren des Apache-Dienstes auch beendet werden muss?
    > Systemd verwendet diese Kernelfeatures nicht, damit es so schön unportabel
    > ist, sondern weil es schlicht nötig und sinnvoll ist, um die gewünschten
    > Features zu implementieren.
    >
    Cgroup ist ein Ansatz Resourcen zu beschränken, gegen Kernel Features hab' ich auch nichts. Mich störts wenn der Kram hoch bis ins DE reicht. Dort hat er nichts verloren, plattformspez. gehört da nicht hin.
    > > MIR IST NOCH
    > > KEIN BUG IN DEN INIT SCRIPTEN UND DARUNTER UNTERGEKOMMEN.
    > Ja, weil irgendjemand bei Deiner Distri Zeit und Arbeit investiert, um sie
    > zu debuggen. Eine systemd-Unit ist mit Sicherheit einfacher zu schreiben,
    > und einen Bug in systemd diesbezüglich habe ich auch noch nie gesehen. Du?
    >
    > > Der Bug(bspw. " separate-usr-is-broken") ist doch bereits im Quellcode
    > > funktioniert nicht, aber trolle nur weiter.
    > Du beziehst Dich wohl auf das hier:
    > freedesktop.org
    > Das hat exakt gar nichts mit systemd zu tun. Zitat:
    > "systemd works fine with /usr on a separate file system that is not
    > pre-mounted at boot. "
    > Und übrigens auch das hier: "The message is merely a warning. You can
    > choose to ignore it."
    >
    > > Oja ein Interface wovon es stets nur eine Implementierung gibt, ganz
    > toll.
    > Es gibt nur eine Implementierung, weil die Konkurrenz sich (bisher) dagegen
    > entschieden hat, das Interface zu implementieren. Das ist aber kein Problem
    > in systemd, da das Interface für socket activation so ziemlich die
    > simpelste Möglichkeit darstellt.

    Der Sinn eines Interface ist nicht Möglichkeiten einer Alternativimplementierung aufzuzeigen. Entweder findet er praktische Verwendung oder es bleibt bei einem Alibi Feature.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  7. Re: Systemd statt Consolekit

    Autor: Hello_World 29.02.12 - 15:57

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Die "Ausgereiftheit" wird erst die Praxis noch zeigen müssen.
    In der Praxis funktioniert systemd jetzt schon ausgezeichnet.

    > Und wie du
    > schon sprachst, Shell Skripte ähneln sich stark und damit sie wieder an
    > Anfang.
    Das ist kein deutscher Satz, und ich habe keine Ahnung, was Du damit sagen willst.

    > Man ersetzt was simples ausgereiftes gegen komplexen C Code, der
    > nach deiner Meinung weniger komplex ist als Shell Code.
    Der Shell-Code ist nur bei oberflächlicher Betrachtung simpel. In Wirklichkeit hängt auch hier ein riesiger Haufen C-Code dahinter, eben durch die ganzen Tools, die verwendet werden. Aber das ignorierst Du ja beständig...

    > Nö, man beschränkt sich auf die nötigen und sichert ab, dass die wenigstens
    > eine Weile Bestand haben.
    cgroups _sind_ nötig, um die Features zu implementieren, die systemd bietet. Man benutzt diese Features nicht nur aus Spaß. Das von mir gebrachte Beispiel für ein Feature, das nur mit cgroups implementierbar ist, hast Du folgerichtig auch ignoriert.

    > Cgroup ist ein Ansatz Resourcen zu beschränken, gegen Kernel Features hab'
    > ich auch nichts. Mich störts wenn der Kram hoch bis ins DE reicht. Dort hat
    > er nichts verloren, plattformspez. gehört da nicht hin.
    POSIX etc. sehen keine Möglichkeiten vor, um z. B. über hotplugging-Events informiert zu werden, oder für direct rendering. Was soll man denn da machen, wenn nicht auf Linux-spezifische Features zurückgreifen?! Wenn Dir Portabilität so wichtig, dann beteilige Dich daran, ansonsten hör auf, hier über die Arbeit anderer Leute herzuziehen.

    > Der Sinn eines Interface ist nicht Möglichkeiten einer
    > Alternativimplementierung aufzuzeigen. Entweder findet er praktische
    > Verwendung oder es bleibt bei einem Alibi Feature.
    Was soll Poettering denn Deiner Ansicht nach tun?! Die SMF- und BSD-init-Entwickler mit einer Pistole am Kopf zwingen, seine Interfaces zu implementieren? Er hat genau das gemacht, was er machen konnte: er hat Interfaces designt, die portabel sind, und diese frühzeitig auf Mailinglisten zur Diskussion gestellt. Wenn der Rest der Welt nicht mitmacht - Pech für sie.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Betriebswirtin / (Wirtschafts-)Informatikerin / Wirtschaftsingenieurin als SAP-Architektin ... (m/w/d)
    Max-Planck-Gesellschaft zur Förderung der Wissenschaften e.V., München
  2. Software Entwickler Embedded Systems - C++ / Linux (m/w/d)
    OTT Hydromet GmbH, Kempten
  3. Consultant IT-Security (m/w/d)
    operational services GmbH & Co. KG, Berlin, Hamburg, Wolfsburg
  4. Scrum Master (m/w/d)
    Scheidt & Bachmann System Technik GmbH, Kiel

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 49,99€
  2. 3,89€
  3. 19,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de