1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Freier Desktop: Erste Beta von…
  6. Thema

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
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Re: Systemd statt Consolekit

    Autor: bstea 29.02.12 - 08:26

    ChilliConCarne schrieb:
    --------------------------------------------------------------------------------
    > bstea schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Was ist denn daran kompliziert, sich dem Problem anzunähern indem ich
    > ein
    > > paar print's platziere?
    > Ein *paar* prints bei SysVInit?
    >
    Du weißt schon das SysV Init Shell Skripte nutzt?
    > > Und die Kommentare im Quellcode erwecken auf
    > > mich nicht den Eindruck, dass man fehlerfreie Software ausliefern will.
    > Bitte? Nur mal ein Beispiel:
    > cgit.freedesktop.org
    > Ich habe selten so ausführlich dokumentierten Code gesehen. Wie zum Henker
    > kommt man da zur Aussage, dass das ein Indiz für Codeschlamperei sein soll?
    > Das liest sich wie Hello_World schon sagte arg nach FUD. Wären die
    > Kommentare nur Einzeiler würden die Kritiker über schlecht
    > nachvollziehbaren Code gackern. Wie sollten denn jetzt am Beispiel
    > sd-daemon.h denn deiner Meinung nach die Kommentare aussehen, damit man da
    > nichts Negatives mehr reininterpretieren kann?
    Schön das du eine neue Baustelle aufmachst, wovon ich gar nicht gesprochen habe. Bugs bleiben Bugs, da helfen auch keine Schönheitspreise beim Quellcode.

    --
    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!

  2. Re: Systemd statt Consolekit

    Autor: ChilliConCarne 29.02.12 - 09:38

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Du weißt schon das SysV Init Shell Skripte nutzt?
    Ich habe den Begriff "paar" extra hervorgehoben. Es dürfte denke ich klar sein, was ich damit meine. Bitte verkaufe mich mit solch rethorischen Fragen nicht für dumm.

    > Schön das du eine neue Baustelle aufmachst,
    > wovon ich gar nicht gesprochen habe.
    Ich mache eine neue Baustelle auf? Ich zitiere dich *nochmal*:
    > > > Und die Kommentare im Quellcode erwecken auf
    > > > mich nicht den Eindruck, dass man fehlerfreie Software ausliefern
    > > > will.
    Welche andere Aussage machst du denn damit?

    > Bugs bleiben Bugs, da helfen auch keine Schönheitspreise beim
    > Quellcode.
    Mal zwei Beispiele:
    http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sysvinit;dist=stable (ca. 65 Bugs)
    https://admin.fedoraproject.org/pkgdb/acls/bugs/systemd (98 Bugs)

    Ohne jetzt auf die Bugs einzeln einzugehen, da auf der Fedora Seite keine Einteilung wie bie Debian vorgenommen wird, würde ich sagen, dass hier eine Bug Diskussion über SysVInit vs systemd eigentlich müßig ist. Wir haben hier ca. ein Verhältnis von 2:3 und für ein so junges init System, ist das im Vergleich zu einem, das schon 15 Jahre oder älter ist, schonmal ein guter Start. Nicht zu vergessen ist, dass wie Hello_World schon erwähnte, die ganzen Distributoren über die Jahre bei sysvinit ein HAUFEN Bugfixing und Patchwork bereits beigetragen haben. In der Praxis merke ich jedoch von diesem 2:3 Verhältnis nix. Gut ich nutze zZ Arch und ob dieses hier gleich ist, weiß ich nicht, da Arch ja einen BSD init verwendet. Jedoch spricht es schon mehr als deutlich für sich, wenn ich den init Prozess einfach mal auf systemd umstelle und auf Anhieb wirklich *alles* funktioniert. Das einzig Nervige damals war, dass beim Shutdown systemd ewig auf das Beenden der net.profiles wartete. Das nächste behebende Update war aber so schnell da, dass ich da gar nicht mal nachsehen musste.

    Ach ja, und gute Quelltext Dokumentation hat nix mit Schönheitspreisen zu tun. Die ist essentiell. Ohne dir jetzt etwas unterstellen zu wollen, also eine reine Mutmaßung, aber wer sowas behauptet hat mMn nicht wirklich jemals die Hand an großen Projekten gehabt.

  3. Re: Systemd statt Consolekit

    Autor: bstea 29.02.12 - 10:03

    ChilliConCarne schrieb:
    --------------------------------------------------------------------------------
    > bstea schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Du weißt schon das SysV Init Shell Skripte nutzt?
    > Ich habe den Begriff "paar" extra hervorgehoben. Es dürfte denke ich klar
    > sein, was ich damit meine. Bitte verkaufe mich mit solch rethorischen
    > Fragen nicht für dumm.
    >
    Weil wir wieder aneinander vorbei reden? Wenn ich einen Fehler identifizieren will klasstere ich nicht das Skript mit zus. Ausgaben voll sondern interessiere mich nur für den Weg zum Ergebnis also den Inhalt von Variablen, Rückgabewert bzw. schau mir die Logs an. Wie sähe es denn bei Systemd aus, neu übersetzen, Debugger anschmeißen, Dokus lesen was wo sinnvolle Rückgabewere wären, C Code Verständnis vorrausgesetzt. Keine wirkliche Arbeitserleichterung.
    > > Schön das du eine neue Baustelle aufmachst,
    > > wovon ich gar nicht gesprochen habe.
    > Ich mache eine neue Baustelle auf? Ich zitiere dich *nochmal*:
    > > > > Und die Kommentare im Quellcode erwecken auf
    > > > > mich nicht den Eindruck, dass man fehlerfreie Software ausliefern
    > > > > will.
    > Welche andere Aussage machst du denn damit?
    >
    Hier ist es ähnlich. Ich spreche von Fehlern die bereits im Code dokumentiert sind und du wirfst mit Dokumentationsqualität.
    > > Bugs bleiben Bugs, da helfen auch keine Schönheitspreise beim
    > > Quellcode.
    > Mal zwei Beispiele:
    > bugs.debian.org (ca. 65 Bugs)
    > admin.fedoraproject.org (98 Bugs)
    >
    > Ohne jetzt auf die Bugs einzeln einzugehen, da auf der Fedora Seite keine
    > Einteilung wie bie Debian vorgenommen wird, würde ich sagen, dass hier eine
    > Bug Diskussion über SysVInit vs systemd eigentlich müßig ist. Wir haben
    > hier ca. ein Verhältnis von 2:3 und für ein so junges init System, ist das
    > im Vergleich zu einem, das schon 15 Jahre oder älter ist, schonmal ein
    > guter Start. Nicht zu vergessen ist, dass wie Hello_World schon erwähnte,
    > die ganzen Distributoren über die Jahre bei sysvinit ein HAUFEN Bugfixing
    > und Patchwork bereits beigetragen haben. In der Praxis merke ich jedoch von
    > diesem 2:3 Verhältnis nix. Gut ich nutze zZ Arch und ob dieses hier gleich
    > ist, weiß ich nicht, da Arch ja einen BSD init verwendet. Jedoch spricht es
    > schon mehr als deutlich für sich, wenn ich den init Prozess einfach mal auf
    > systemd umstelle und auf Anhieb wirklich *alles* funktioniert. Das einzig
    > Nervige damals war, dass beim Shutdown systemd ewig auf das Beenden der
    > net.profiles wartete. Das nächste behebende Update war aber so schnell da,
    > dass ich da gar nicht mal nachsehen musste.
    >
    > Ach ja, und gute Quelltext Dokumentation hat nix mit Schönheitspreisen zu
    > tun. Die ist essentiell. Ohne dir jetzt etwas unterstellen zu wollen, also
    > eine reine Mutmaßung, aber wer sowas behauptet hat mMn nicht wirklich
    > jemals die Hand an großen Projekten gehabt.

    Und nochmal, du gehst auf das Geschriebene nicht ein. Wenn Bugs in SysV Init bekannt sind, dann wäre die oberste Prioriät diese zu fixen, statt ein neues Projekt aus dem Boden zu stampfen in der Hoffnung, weniger Bugs damit zu erzeugen. Dokumentation ist toll, macht aber ein Projekt nicht besser, wenn der Ansatz ist: Mir egal wenn's Fehler hat, im Zweifel schreibe ich was neues.
    Ich kenne kaum ein Projekt, wo die Dokumentation den Stand der Entwicklung widerspiegelt.

    --
    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!

  4. Re: Systemd statt Consolekit

    Autor: ChilliConCarne 29.02.12 - 12:25

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Wenn ich einen Fehler
    > identifizieren will klasstere ich nicht das Skript mit zus. Ausgaben voll
    Ok ...

    > sondern interessiere mich nur für den Weg zum Ergebnis also den Inhalt von
    > Variablen, Rückgabewert bzw. schau mir die Logs an.
    Und du kannst garantieren, dass mit ein "paar" sukzessive gesetzten Ausgaben der Fehler bald gefunden ist? Je nach Fehler wohl kaum. Dann ist es Jacke wie Hose ob du haufenweise Ausgaben setzt oder zig mal mit neuen Ausgaben schaust was rauskommt. Zudem gibt es zum Debuggen von Shell Skripten eher andere Mittel:
    http://www.jan-trippler.de/de/script_tipps/debug.html
    Es ist zwar weit verbreitet, jedoch allgemein verpöhnt print als Debug Werkzeug herzunehmen.

    > neu übersetzen,
    1x make mit Debug Makro

    > Debugger anschmeißen,
    1x gdb executeable

    > Dokus lesen was wo sinnvolle Rückgabewere wären
    Bei den haufenweisen Shell Skripten etwa nicht? Du kannst mir kaum erzählen, dass du bei irgendeiner Variable die an zig Orten verwendet wird, sofort jede Auswirkung einer Änderung vorhersagen kannst. Die Komplexität liegt dann nicht mehr an der Sprache, sondern an den Algorithmen an sich. Der etwas peniblere Umgang mit C armotisiert sich hier bei wachsender LOC schnell.

    > C Code Verständnis vorrausgesetzt.
    Bei SysVInit sind etwa keine Shell Kenntnisse vorausgesetzt? Die Skripte sind teilweise nicht ohne. Die komplett zu verstehen ist mit Sicherheit nicht mit ein bisschen Erfahrung mit echo und Umgebungsvariablen getan, oder ein bisschen Editieren der ~/.bashrc.

    > Keine wirkliche Arbeitserleichterung.
    Und auch keine wirkliche Erschwerung, sofern man sich mit C auskennt. Das Einzige was man hier argumentativ stehen lassen könnte, ist dass man eher mit Shell Skripten als mit C in ernsthaften Kontakt kommt und da tendenziell die Erfahrung größer sein dürfte. Auch muss man nicht zwingend C können, wenn mal etwas nicht bei systemd funktionieren will. Ein Blick in die services reicht in den meißten Fällen um alles wieder flott zu bekommen. Und die sind echt "freundlich" da es sich nur um ini-artige Textdateien handelt.

    > Ich spreche von Fehlern die bereits im Code
    > dokumentiert sind
    Ich habe ein paar *.c und *.h Sourcen nur flüchtig überflogen. Kannst du mir da einen betreffenden Kommentar nennen?

    > dann wäre die oberste Prioriät diese zu fixen, statt ein
    > neues Projekt aus dem Boden zu stampfen
    Hier bewegen wir uns denke ich eher auf einer höheren Frage, wann ein ggf. altes Konzept obsolet wird. Auch wenn die Möglichkeit besteht ein vorhandenes Projekt zu fixen, ist eine Überlegung für ein Neudesign nicht ausgeschlossen. Das zeigt sich vor allem in diesem Beispiel darin, dass systemd afaik primär nicht wegen irgendwelcher Bugs in SysVinit ins Leben gerufen worden ist, sondern neue Features auch vom Linux Kernel bereit gestellte zu nutzen und eine *wirkliche* Vereinheitlichung der verschiedenen Init Systeme unter den Distributoren zu entwickeln. Ein Diskussion ob wir das für gut oder schlecht halten, würde hier denke ich den Rahmen sprengen, jedoch sei gesagt, dass irgendwann mal Zeiten kommen wo evtl. neue Konzepte und Architektur Designs einfach Vorteile bringen und diese sich im 'alten' System nicht mehr durch Bugfixing realisieren lassen. Bugfixing behebt wie gesagt nur Bugs ändert aber nicht die komplette Arbeitsweise einer Software.

    Ist in etwa das Selbe Dilemma wie mit X und Wayland.

    > Ich kenne kaum ein Projekt, wo die Dokumentation den Stand der Entwicklung
    > widerspiegelt.
    Es ging auch nicht um den Stand der Entwicklung, sondern dass eine ausführliche Quelltext Doku das Erste ist was auch dessen Wartbarkeit erhöht. Vor allem in die Zukunft betrachtet. Man siehe nur mal die autotools. Auf irgendeiner Mailingliste kristallisierte sich irgendwann heraus, dass da ein Haufen verweißter Code existiert, bei dem keiner so recht weiß, was da eigentlich noch passiert. Warum? Fehlende Quelltext Doku. Daher schießen seit einer Weilen alle möglichen Alternativen wie CMake, Scons, Waf usw. aus dem Boden.

  5. Re: Systemd statt Consolekit

    Autor: Hello_World 29.02.12 - 16:01

    Gib's auf, bei dem Typen ist das hoffnungslos.

  1. Thema
  1. 1
  2. 2
  3. 3

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. Leiter (m/w/d) Software Architektur
    Scheidt & Bachmann Fare Collection Systems GmbH, Mönchengladbach
  2. Netzwerkadministrator im Leitsystemumfeld (w/m/d)
    Netze BW Wasser GmbH, Stuttgart
  3. Softwarearchitekt (m/w/d) Embedded Java
    VIVAVIS AG, Ettlingen
  4. Projektmanager (m/w/d) Süddeutschland
    NTT Germany AG & Co. KG, Bad Homburg, Einsatzgebiet Süddeutschland

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. The Witcher 3 - Game of the Year Edition (GOG Key) für 12,49€, Rainbow Six Siege - Deluxe...
  2. Asus Chromebook CM3 10,5 Zoll Chromebook inkl. Stylus, Chromebook mit 10,5 Zoll Touchscreen 4GB...
  3. (u. a. Wochenangebote mit Assassin's Creed Odyssey - Gold Edition für 22,99€, Dragon Ball...
  4. 265€ (Bestpreis)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Gaming und Inklusion: Schnelles Tastendrücken heißt Game Over
Gaming und Inklusion
Schnelles Tastendrücken heißt Game Over

Körperlich beeinträchtigte Menschen haben es nicht leicht in Games. Dabei wäre es möglich, Videospiele inklusiver zu machen. Das erkennt langsam auch die Industrie.
Ein Bericht von Denis Gießler

  1. Patente EA gibt Ping-System von Apex Legends frei
  2. Apple Geräte bekommen mehr Funktionen für Barrierefreiheit
  3. Microsoft Mindestens vier Schwierigkeitsgrade für Barrierefreiheit

Von Cubesats zu Disksats: Satelliten als fliegende Scheiben
Von Cubesats zu Disksats
Satelliten als fliegende Scheiben

Leichte und billige Satelliten, die auch zu Mond und Mars fliegen können: Aerospace Corp hat den neuen Standardformfaktor Disksats entwickelt.
Von Frank Wunderlich-Pfeiffer

  1. Raumfahrt Strahlungsresistente Speicher für die Raumfahrt von Infineon
  2. Raumfahrt Esa und finnisches Projekt bauen einen Satelliten aus Holz
  3. Raumfahrt MEV-2 bringt Satellit neue Energie

Y - The Last Man: Eine Welt der Frauen
Y - The Last Man
Eine Welt der Frauen

Vor knapp 20 Jahren wurde das erste Comic-Heft veröffentlicht, einige Jahre war die Fernsehserie Y - The Last Man in Entwicklung. Jetzt ist sie endlich bei Disney+.
Eine Rezension von Peter Osteried

  1. Shang-Chi and the Legend of the 10 Rings Marvel-Film kommt später als erwartet zu Disney+
  2. Disney+ TV-Sender fordern Filme für 1 Monat ohne Streamingkonkurrenz
  3. Disney+ Disney plant 60 europäische Serien bis 2024