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: Hello_World 28.02.12 - 13:49

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Wenn dadurch alle andere Unixe ausgesperrt werden, sehe ich das schon
    > problematisch.
    Niemand wird ausgesperrt. Es steht den Entwicklern anderer Systeme frei, die Linux-only-Funktionalität, die systemd erfordert, nachzubauen. Auch steht es ihnen frei, systemd zu forken und auf ihr System zu portieren, oder einfach einen systemd-Klon für ihr System zu schreiben (die Interfaces, die systemd anbietet, sind sehr einfach gehalten und können auf jedem Unix implementiert werden). Wenn sie sich dagegen entscheiden, dann ist das ihr Problem. Es ist ganz gewiss kein Grund, die Vorteile, die der Linux-Kernel gegenüber anderen Systemen bietet, nicht zu nutzen. Systemd benutzt ja nicht zum Spaß Linux-only-Interfaces.

    > Noch ist dieser Teil optional aber die Geschichte hat
    > gezeigt, irgendwann wird wieder einer kommen, die Alternative entfernen,
    > "weil das ohnehin keiner mehr nutzt" (Linux).
    > Schon jetzt ist die Entwicklung problematisch, praktisch jedes
    > Nichtlinuxsystem patcht sich seine DE zurecht.
    Und selbst wenn: who cares? De facto ist Linux das einzige Unix, das in nennenswertem Umfang auf dem Desktop eingesetzt wird (sieht man einmal von Mac OS X ab, das seinen eigenen Desktop und sein eigenes init-System hat). Wenn andere Unixe Interesse an einem guten Desktop haben, können sie sich gern an der Entwicklung beteiligen oder auf ihrem System Linux-kompatible Interfaces implementieren. Wenn sie das nicht wollen - Pech gehabt. Man kann nicht von Linux-Entwicklern erwarten, die Probleme anderer Leute zu lösen.

  2. Re: Systemd statt Consolekit

    Autor: drago01 28.02.12 - 13:50

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Wenn dadurch alle andere Unixe ausgesperrt werden, sehe ich das schon
    > problematisch.

    Es wird nichts bewusst ausgesperrt es werden aber Features die nur der Linux Kernel bereitstellt verwendet, die durchaus sinnvoll sind (z.B cgroups).



    1 mal bearbeitet, zuletzt am 28.02.12 13:50 durch drago01.

  3. Re: Systemd statt Consolekit

    Autor: bstea 28.02.12 - 14:06

    Cgroups ist die Gruppierung von Prozessen zur Resourcenoptimierung. Jails geht in die Richtung, Cgroups ist aber kein Feature das man unbedingt brauchen würde.
    Lies doch mal die Abhängigkeiten von Systemd, selbst unter Linux benötigst du bestimmte Kernelversionen, damit der Kram so läuft wie gedacht.

    --
    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: bstea 28.02.12 - 14:13

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > > Systemd ist nicht komplex?
    > Nein. Erklär doch bitte mal, was daran so komplex sein soll. Ich habe
    > bereits Beispiele für Sachen genannt, die durch systemd einfacher werden.
    >
    Was ist denn an Shell Skripten komplex, die Anzahl der LoC? Shell Skripte kannst du relativ simpel mit gezielten Ausgaben kontrollieren. Systemd, dafür darf ich neu übersetzen und Debugger nutzen, klasse Vereinfachung. Soll ich im Problemfall auf den Produktivsystem eine Entwicklungsumgebung installieren?
    > > Hast du dir mal angeschaut, wo überall Systemd zum Einsatz kommen soll
    > und
    > was für Abhängigkeiten direkt zum Linux Kernel bestehen?
    > Ja, die systemd-Implementierung ist nicht portabel, weil das die
    > Implementierung wesentlich vereinfacht - wieso sollte sich Poettering auch
    > das Leben schwer machen, um Systeme zu unterstützen, die ihn nicht
    > interessieren? Die Interfaces, die systemd bereitstellt, z. B. das
    > Übergabeprotokoll für den Socket bei socket-based activation, können
    > hingegen auf jedem Unix sehr einfach implementiert werden.

    Systemd wurde explizit für Linux entworfen. Launchd wäre eine portable Lösung gewesen, die aber nicht so nah am Linuxkernel klebt.

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

  5. Re: Systemd statt Consolekit

    Autor: bstea 28.02.12 - 14:24

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > bstea schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wenn dadurch alle andere Unixe ausgesperrt werden, sehe ich das schon
    > > problematisch.
    > Niemand wird ausgesperrt. Es steht den Entwicklern anderer Systeme frei,
    > die Linux-only-Funktionalität, die systemd erfordert, nachzubauen. Auch
    > steht es ihnen frei, systemd zu forken und auf ihr System zu portieren,
    > oder einfach einen systemd-Klon für ihr System zu schreiben (die
    > Interfaces, die systemd anbietet, sind sehr einfach gehalten und können auf
    > jedem Unix implementiert werden). Wenn sie sich dagegen entscheiden, dann
    > ist das ihr Problem. Es ist ganz gewiss kein Grund, die Vorteile, die der
    > Linux-Kernel gegenüber anderen Systemen bietet, nicht zu nutzen. Systemd
    > benutzt ja nicht zum Spaß Linux-only-Interfaces.
    >
    Klasse Logik, Solaris implementiert mal Systemd, BSDs implementiert mal Systemd, Rest wenn euch zu langweilig implementiert mal Systemd.
    Forken macht man nur dann Sinn wenn man die Resourcen hat und die Sicherheit das überlebt so einige Jahre ohne gravierende Änderungen. Aber dank Kernelabhängigkeiten wäre das zu mühsam ständig zu aktualisieren.
    PS: Ich kann mir schwer vorstellen das irgendjemand jemals Systemd portieren würde, alleine wegen der viralen Lizenz, die auch andere Projekte beeinträchtigt.

    > > Noch ist dieser Teil optional aber die Geschichte hat
    > > gezeigt, irgendwann wird wieder einer kommen, die Alternative entfernen,
    > > "weil das ohnehin keiner mehr nutzt" (Linux).
    > > Schon jetzt ist die Entwicklung problematisch, praktisch jedes
    > > Nichtlinuxsystem patcht sich seine DE zurecht.
    > Und selbst wenn: who cares? De facto ist Linux das einzige Unix, das in
    > nennenswertem Umfang auf dem Desktop eingesetzt wird (sieht man einmal von
    > Mac OS X ab, das seinen eigenen Desktop und sein eigenes init-System hat).
    > Wenn andere Unixe Interesse an einem guten Desktop haben, können sie sich
    > gern an der Entwicklung beteiligen oder auf ihrem System Linux-kompatible
    > Interfaces implementieren. Wenn sie das nicht wollen - Pech gehabt. Man
    > kann nicht von Linux-Entwicklern erwarten, die Probleme anderer Leute zu
    > lösen.

    Du meinst der gemeine Hobbyprogrammierer geht zu Gnome und verhindert das Red Hat das System vermurkst. Was glaubst du, wer wohl den Ton dort angibt, Privatpersonen?

    --
    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: Hello_World 28.02.12 - 15:57

    > Was ist denn an Shell Skripten komplex
    Scripte in einer turingvollständigen Sprache sind inhärent komplexer als deklarative Konfigurationsdateien, deswegen setzen letztere sich auch zunehmend in init-Systemen durch. launchd verwendet plist-Dateien, SMF (von Solaris) verwendet XML-Konfigurationsdateien. Das machen die sicher nicht, weil Shell-Scripte so toll sind.

    > Shell Skripte kannst du relativ simpel mit gezielten Ausgaben kontrollieren.
    systemd stellt Werkzeuge bereit, um den Status und die Ausgaben von Prozessen zu überprüfen.

    > Systemd, dafür darf ich neu übersetzen und Debugger nutzen, klasse Vereinfachung.
    Das ist nur bei Bugs in systemd nötig, und Bugs können auch mit sysvinit auftreten. De facto ist die Situation dort was das angeht sogar noch wesentlich unübersichtlicher, da Bugs nicht nur in sysvinit, sondern auch in bash, sed, grep, awk, ps, cat, ... stecken können. Insgesamt ist an einem durchschnittlichen Bootvorgang mit sysvinit _viel_ mehr Code beteiligt (sowohl C- als auch Shell-Code) als bei einem durchschnittlichen Boot mit systemd.

    > Systemd wurde explizit für Linux entworfen.
    Ja, die Implementierung. Die Interfaces sind aber portabel. Systemd tut für die socket activation genau zwei Sachen: es setzt ein paar Umgebungsvariablen und vererbt ein paar Filedeskriptoren. Das geht auf ausnahmslos jedem Unix.

  7. Re: Systemd statt Consolekit

    Autor: Hello_World 28.02.12 - 16:18

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Klasse Logik, Solaris implementiert mal Systemd, BSDs implementiert mal
    > Systemd, Rest wenn euch zu langweilig implementiert mal Systemd.
    Solaris hat SMF und die BSDs haben ihre eigenen init-Implementierungen. Wenn sie es bisher geschafft haben, ihr eigenes init zu implementieren, wieso soll das jetzt auf einmal nicht mehr gehen?

    > PS: Ich kann mir schwer vorstellen das irgendjemand jemals Systemd
    > portieren würde,
    Das ist auch gar nicht nötig. Es reicht, wenn man die einfachen, portablen Interfaces implementiert, die systemd verwendet. Socket activation ist trivial: systemd setzt ein paar Umgebungsvariablen und vererbt ein paar File-Deskriptoren, nichts weiter. Das geht auf ausnahmslos jedem Unix, und wenn die SMF- oder BSD-init-Entwickler nur wollen, können sie dieses Feature mit Leichtigkeit integrieren.

    > alleine wegen der viralen Lizenz, die auch andere Projekte
    > beeinträchtigt.
    Unfug, die GPL beeinträchtigt nur abgeleitete Werke.

    > Du meinst der gemeine Hobbyprogrammierer geht zu Gnome und verhindert das
    > Red Hat das System vermurkst. Was glaubst du, wer wohl den Ton dort angibt,
    > Privatpersonen?
    Zeig mir doch bitte mal einen einzigen Fall, in dem ein Gnome-Patch abgelehnt wurde, weil er die Portabilität auf nicht-Linux-Systeme verbessert. Das Problem ist nicht, dass Red Hat oder sonst irgendjemand ein Problem damit hätte, andere Systeme zu unterstützen, sondern schlicht und einfach, dass die Ressourcen dafür fehlen und sich halt niemand für Solaris oder FreeBSD auf dem Desktop interessiert, und deswegen auch niemand dafür entwickelt.

  8. Re: Systemd statt Consolekit

    Autor: ChilliConCarne 28.02.12 - 16:21

    Schnarchnase schrieb:
    --------------------------------------------------------------------------------
    > tatsächlich glaube ich nicht, dass systemd den Bootvorgang merkbar
    > beschleunigen kann

    Oh doch! Ich kann versichern, dass es das *deutlich* merkbar tut.

  9. Re: Systemd statt Consolekit

    Autor: Schnarchnase 28.02.12 - 16:38

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > Darf man fragen, wovon Du sprichst? Systemd wird über Textdateien im
    > ini-Format konfiguriert.

    Ich meine gelesen zu haben, dass systemd seine Konfiguration in Binärdateien ablegt, bzw die „Initskripte“ Binärdateien sind (wenn nicht das Fallback auf die SysVinit-Skript genutzt wird). Sollte das nicht der Fall sein, habe ich nichts gesagt.

    > Nein, muss man nicht. update-grub ist nur ein Wrapper um grub-mkconfig, und
    > das generiert nur eine neue /boot/grub/grub.cfg. Diese Datei kann man auch
    > von Hand editieren, wenn man das lieber mag.

    Mein Distributor rät davon ab diese Datei per Hand zu editieren, vermutlich nicht ohne guten Grund.

  10. Re: Systemd statt Consolekit

    Autor: ChilliConCarne 28.02.12 - 16:45

    Schnarchnase schrieb:
    --------------------------------------------------------------------------------
    > Ich meine gelesen zu haben, dass systemd seine Konfiguration in
    > Binärdateien ablegt, bzw die „Initskripte“ Binärdateien sind
    > (wenn nicht das Fallback auf die SysVinit-Skript genutzt wird). Sollte das
    > nicht der Fall sein, habe ich nichts gesagt.
    Du hast in dem Fall wirklich nichts gesagt.

    > Mein Distributor rät davon ab diese Datei per Hand zu editieren, vermutlich
    > nicht ohne guten Grund.
    Weil er erstmal pauschal davon ausgeht, dass du nicht weißt was du tust.

  11. Re: Systemd statt Consolekit

    Autor: Hello_World 28.02.12 - 16:57

    Schnarchnase schrieb:
    --------------------------------------------------------------------------------
    > Ich meine gelesen zu haben, dass systemd seine Konfiguration in
    > Binärdateien ablegt, bzw die „Initskripte“ Binärdateien sind
    Tja, das ist Quatsch. Systemd wird über Textdateien im ini-Format konfiguriert.

    > > Nein, muss man nicht. update-grub ist nur ein Wrapper um grub-mkconfig,
    > und
    > > das generiert nur eine neue /boot/grub/grub.cfg. Diese Datei kann man
    > auch
    > > von Hand editieren, wenn man das lieber mag.
    >
    > Mein Distributor rät davon ab diese Datei per Hand zu editieren, vermutlich
    > nicht ohne guten Grund.
    Der Grund dafür ist ganz einfach: wenn ein Kernel-Update installiert wird, müssen neue Boot-Einträge in der grub.cfg angelegt werden. Die einfachste Möglichkeit dafür ist, die alte grub.cfg wegzuschmeißen und mit grub-mkconfig eine neue zu generieren, und genau das passiert. Wenn Dir das nicht passt, musst Du den entsprechenden Mechanismus deiner Distri ausschalten; unter Debian (und vermutlich Ubuntu) sind hierfür die Scripte in /etc/kernel zuständig.
    Übrigens kannst Du auch Einträge in /boot/grub/custom.cfg anlegen. Änderungen in dieser Datei wirken sich sofort aus, ohne dass man erst update-grub laufen lassen müsste.

  12. Re: Systemd statt Consolekit

    Autor: bstea 28.02.12 - 17:39

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > > Was ist denn an Shell Skripten komplex
    > Scripte in einer turingvollständigen Sprache sind inhärent komplexer als
    > deklarative Konfigurationsdateien, deswegen setzen letztere sich auch
    > zunehmend in init-Systemen durch. launchd verwendet plist-Dateien, SMF (von
    > Solaris) verwendet XML-Konfigurationsdateien. Das machen die sicher nicht,
    > weil Shell-Scripte so toll sind.
    >
    > > Shell Skripte kannst du relativ simpel mit gezielten Ausgaben
    > kontrollieren.
    > systemd stellt Werkzeuge bereit, um den Status und die Ausgaben von
    > Prozessen zu überprüfen.
    >
    > > Systemd, dafür darf ich neu übersetzen und Debugger nutzen, klasse
    > Vereinfachung.
    > Das ist nur bei Bugs in systemd nötig, und Bugs können auch mit sysvinit
    > auftreten. De facto ist die Situation dort was das angeht sogar noch
    > wesentlich unübersichtlicher, da Bugs nicht nur in sysvinit, sondern auch
    > in bash, sed, grep, awk, ps, cat, ... stecken können. Insgesamt ist an
    > einem durchschnittlichen Bootvorgang mit sysvinit _viel_ mehr Code
    > beteiligt (sowohl C- als auch Shell-Code) als bei einem durchschnittlichen
    > Boot mit systemd.
    >
    Was ist denn daran kompliziert, sich dem Problem anzunähern indem ich ein paar print's platziere? 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. Und die Kommentare im Quellcode erwecken auf mich nicht den Eindruck, dass man fehlerfreie Software ausliefern will.

    > > Systemd wurde explizit für Linux entworfen.
    > Ja, die Implementierung. Die Interfaces sind aber portabel. Systemd tut für
    > die socket activation genau zwei Sachen: es setzt ein paar
    > Umgebungsvariablen und vererbt ein paar Filedeskriptoren. Das geht auf
    > ausnahmslos jedem Unix.
    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.

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

  13. Re: Systemd statt Consolekit

    Autor: bstea 28.02.12 - 17:48

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > bstea schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Klasse Logik, Solaris implementiert mal Systemd, BSDs implementiert mal
    > > Systemd, Rest wenn euch zu langweilig implementiert mal Systemd.
    > Solaris hat SMF und die BSDs haben ihre eigenen init-Implementierungen.
    > Wenn sie es bisher geschafft haben, ihr eigenes init zu implementieren,
    > wieso soll das jetzt auf einmal nicht mehr gehen?
    >
    Keiner entsorgt freiwillig ein funktionierendes System oder flanscht GPL Code aus Jux in seine Umgebung.
    > > PS: Ich kann mir schwer vorstellen das irgendjemand jemals Systemd
    > > portieren würde,
    > Das ist auch gar nicht nötig. Es reicht, wenn man die einfachen, portablen
    > Interfaces implementiert, die systemd verwendet. Socket activation ist
    > trivial: systemd setzt ein paar Umgebungsvariablen und vererbt ein paar
    > File-Deskriptoren, nichts weiter. Das geht auf ausnahmslos jedem Unix, und
    > wenn die SMF- oder BSD-init-Entwickler nur wollen, können sie dieses
    > Feature mit Leichtigkeit integrieren.
    >
    > > alleine wegen der viralen Lizenz, die auch andere Projekte
    > > beeinträchtigt.
    > Unfug, die GPL beeinträchtigt nur abgeleitete Werke.
    >
    Unsinn, jedes Programm welches gegen GPL gelinkt wird ist betroffen.
    > > Du meinst der gemeine Hobbyprogrammierer geht zu Gnome und verhindert
    > das
    > > Red Hat das System vermurkst. Was glaubst du, wer wohl den Ton dort
    > angibt,
    > > Privatpersonen?
    > Zeig mir doch bitte mal einen einzigen Fall, in dem ein Gnome-Patch
    > abgelehnt wurde, weil er die Portabilität auf nicht-Linux-Systeme
    > verbessert. Das Problem ist nicht, dass Red Hat oder sonst irgendjemand ein
    > Problem damit hätte, andere Systeme zu unterstützen, sondern schlicht und
    > einfach, dass die Ressourcen dafür fehlen und sich halt niemand für Solaris
    > oder FreeBSD auf dem Desktop interessiert, und deswegen auch niemand dafür
    > entwickelt.
    Dass hab ich auch nicht behauptet, das etwas abgelehnt wird. Eher werden rücksichtlos "alte Zöpfe" abgeschnitten, die Linuxer häufig nicht betreffen. Keiner hat die Lust und Zeit ständig hinter Eigenbrötlern zu kehren, damit die Funktionalität erhalten bleibt. Mich stört es nicht wenn Legacy Kram im Code ist, solange er noch irgendwo funktioniert.

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

  14. Re: Systemd statt Consolekit

    Autor: bstea 28.02.12 - 17:51

    Wie schlecht muss eigentlich Suspend To RAM funktionieren, dass man sein Rechner ständig hochfahren will und sich über gewonne Sekunden freut? [Rhet. Frage]

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

  15. Re: Systemd statt Consolekit

    Autor: Schnarchnase 28.02.12 - 17:54

    Andersherum gehts auch:
    Wie langsam muss eine SSD sein, dass sich Supsend To Ram wirklich lohnt? ;)

  16. Re: Systemd statt Consolekit

    Autor: Hello_World 28.02.12 - 20:52

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Keiner entsorgt freiwillig ein funktionierendes System oder flanscht GPL
    > Code aus Jux in seine Umgebung.
    Davon war ja auch gar nicht die Rede. Geh doch bitte mal auf das ein, was ich geschrieben habe, und nicht auf das verquere Zeug, das Dein Hirn daraus macht.

    > Unsinn, jedes Programm welches gegen GPL gelinkt wird ist betroffen.
    Offensichtlich hast Du die GPL nie gelesen. Tipp: "Linken" kommt darin nicht vor, "abgeleitetes Werk" (bzw. "derived work") dagegen schon.
    Abgesehen davon: Wieso sollte man überhaupt gegen systemd linken? Das einzige, wogegen man vielleicht linken möchte, ist die sd_daemon.c, und die steht nicht unter GPL, sondern unter der MIT-Lizenz.

    > > > Du meinst der gemeine Hobbyprogrammierer geht zu Gnome und verhindert
    > > das
    > > > Red Hat das System vermurkst. Was glaubst du, wer wohl den Ton dort
    > > angibt,
    > > > Privatpersonen?
    > > Zeig mir doch bitte mal einen einzigen Fall, in dem ein Gnome-Patch
    > > abgelehnt wurde, weil er die Portabilität auf nicht-Linux-Systeme
    > > verbessert. Das Problem ist nicht, dass Red Hat oder sonst irgendjemand
    > ein
    > > Problem damit hätte, andere Systeme zu unterstützen, sondern schlicht
    > und
    > > einfach, dass die Ressourcen dafür fehlen und sich halt niemand für
    > Solaris
    > > oder FreeBSD auf dem Desktop interessiert, und deswegen auch niemand
    > dafür
    > > entwickelt.
    > Dass hab ich auch nicht behauptet, das etwas abgelehnt wird. Eher werden
    > rücksichtlos "alte Zöpfe" abgeschnitten, die Linuxer häufig nicht
    > betreffen.
    Nehmen wir doch mal ein Beispiel: HAL. Die Unterstützung dafür wurde entfernt, weil man es einfach nicht mehr braucht. Linux hat udev, FreeBSD hat devd, Solaris hat sysevent. Wenn Du jetzt gerne devd- oder sysevent-Unterstützung für Gnome oder KDE implementieren möchtest, wird Dich niemand davon abhalten. Der einzige Grund, wieso es nicht gemacht wird, ist, dass diese Systeme auf dem Desktop außer Forentrollen keinen interessieren.

    > Keiner hat die Lust und Zeit ständig hinter Eigenbrötlern zu
    > kehren, damit die Funktionalität erhalten bleibt. Mich stört es nicht wenn
    > Legacy Kram im Code ist, solange er noch irgendwo funktioniert.
    Du bist ja auch nicht derjenige, der mit dem Code arbeiten muss. So funktioniert Open Source eben: wer den Code schreibt, entscheidet auch, was gemacht wird.

  17. Re: Systemd statt Consolekit

    Autor: bstea 28.02.12 - 23:43

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > bstea schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Keiner entsorgt freiwillig ein funktionierendes System oder flanscht GPL
    > > Code aus Jux in seine Umgebung.
    > Davon war ja auch gar nicht die Rede. Geh doch bitte mal auf das ein, was
    > ich geschrieben habe, und nicht auf das verquere Zeug, das Dein Hirn daraus
    > macht.
    >
    Weil dir offensichtlich die Gabe fehlt, Schlussfolgerungen selbständig zu ziehen: Du kannst Systemd nicht teilweise ersetzen entweder schmeißt du deinen Kram raus oder hackst dir jedes Programm zurecht.
    > > Unsinn, jedes Programm welches gegen GPL gelinkt wird ist betroffen.
    > Offensichtlich hast Du die GPL nie gelesen. Tipp: "Linken" kommt darin
    > nicht vor, "abgeleitetes Werk" (bzw. "derived work") dagegen schon.
    > Abgesehen davon: Wieso sollte man überhaupt gegen systemd linken? Das
    > einzige, wogegen man vielleicht linken möchte, ist die sd_daemon.c, und die
    > steht nicht unter GPL, sondern unter der MIT-Lizenz.
    >
    Du kennst die GPL nicht. Du vermischt LGPL mit GPL(http://de.wikipedia.org/wiki/GPL_linking_exception).
    > > > > Du meinst der gemeine Hobbyprogrammierer geht zu Gnome und
    > verhindert
    > > > das
    > > > > Red Hat das System vermurkst. Was glaubst du, wer wohl den Ton dort
    > > > angibt,
    > > > > Privatpersonen?
    > > > Zeig mir doch bitte mal einen einzigen Fall, in dem ein Gnome-Patch
    > > > abgelehnt wurde, weil er die Portabilität auf nicht-Linux-Systeme
    > > > verbessert. Das Problem ist nicht, dass Red Hat oder sonst
    > irgendjemand
    > > ein
    > > > Problem damit hätte, andere Systeme zu unterstützen, sondern schlicht
    > > und
    > > > einfach, dass die Ressourcen dafür fehlen und sich halt niemand für
    > > Solaris
    > > > oder FreeBSD auf dem Desktop interessiert, und deswegen auch niemand
    > > dafür
    > > > entwickelt.
    > > Dass hab ich auch nicht behauptet, das etwas abgelehnt wird. Eher werden
    > > rücksichtlos "alte Zöpfe" abgeschnitten, die Linuxer häufig nicht
    > > betreffen.
    > Nehmen wir doch mal ein Beispiel: HAL. Die Unterstützung dafür wurde
    > entfernt, weil man es einfach nicht mehr braucht. Linux hat udev, FreeBSD
    > hat devd, Solaris hat sysevent. Wenn Du jetzt gerne devd- oder
    > sysevent-Unterstützung für Gnome oder KDE implementieren möchtest, wird
    > Dich niemand davon abhalten. Der einzige Grund, wieso es nicht gemacht
    > wird, ist, dass diese Systeme auf dem Desktop außer Forentrollen keinen
    > interessieren.
    >
    Na danke. Ein Lösung wird entfernt, wer ein Linuxer meint, es gäbe besser Möglichkeiten dies umzusetzen. Weil er keine Lust hat schmeißt er gleich alles raus und implementiert nur eine Lösung. Wen interessieren die anderen, sollen die doch nur machen? Du bist mit Abstand der größte Forentroll/Fanboy.
    > > Keiner hat die Lust und Zeit ständig hinter Eigenbrötlern zu
    > > kehren, damit die Funktionalität erhalten bleibt. Mich stört es nicht
    > wenn
    > > Legacy Kram im Code ist, solange er noch irgendwo funktioniert.
    > Du bist ja auch nicht derjenige, der mit dem Code arbeiten muss. So
    > funktioniert Open Source eben: wer den Code schreibt, entscheidet auch, was
    > gemacht wird.
    Es ist wohl kein Ding, ein paar ifdef im Code zu lassen oder den Kram zu abstrahieren/ auszulagern. Stattdessen wird absichtlich ein funktionierende Ökosystem sabotiert.

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

  18. Re: Systemd statt Consolekit

    Autor: Hello_World 29.02.12 - 02:07

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Weil dir offensichtlich die Gabe fehlt, Schlussfolgerungen selbständig zu
    > ziehen: Du kannst Systemd nicht teilweise ersetzen entweder schmeißt du
    > deinen Kram raus oder hackst dir jedes Programm zurecht.
    Das ist einfach Unsinn. systemd verwendet einige wenige, sehr spezifische Schnittstellen zur Kommunikation mit anderen Programmen.
    1. Umgebungsvariablen und Vererbung von Dateideskriptoren für Socket Activation
    2. Konfigurationsdateien im ini-Format
    3. das D-Bus-Interface
    Das erste lässt sich trivial auch in anderen init-Systemen wie SMF oder BSD-init mit vielleicht einigen Dutzend bis wenigen hundert Codezeilen unterstützen. Die letzten beiden betreffen in erster Linie Verwaltungswerkzeuge wie systemctl und systemadm, die für BSD-init oder SMF ohnehin wenig interessant sind, da die ihre eigenen Werkzeuge mitbringen (bei SMF z. B. die svc*-Tools).

    > Du kennst die GPL nicht. Du vermischt LGPL mit GPL(de.wikipedia.org
    Doch, ich habe sie gelesen, im Gegensatz zu Dir. Da ist der Text, jetzt zeig mir doch bitte mal die Stelle, wo da etwas von Linken steht:
    http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
    Tipp: was nach "END OF TERMS AND CONDITIONS" steht, gehört nicht zur Lizenz.

    > Na danke. Ein Lösung wird entfernt, wer ein Linuxer meint, es gäbe besser
    > Möglichkeiten dies umzusetzen. Weil er keine Lust hat schmeißt er gleich
    > alles raus und implementiert nur eine Lösung. Wen interessieren die
    > anderen, sollen die doch nur machen?
    Tut mir leid, so ist das Leben! Du tust gerade so, als hätten die Solaris- und FreeBSD-Entwickler in irgendeiner Form ein Anrecht darauf, seitens Gnome und KDE unterstützt zu werden. Wenn die einen zeitgemäßen Desktop wollen, dann müssen sie eben etwas dafür tun.

    > Es ist wohl kein Ding, ein paar ifdef im Code zu lassen oder den Kram zu
    > abstrahieren/ auszulagern. Stattdessen wird absichtlich ein funktionierende
    > Ökosystem sabotiert.
    Doch, es ist ein Ding. Dieser Code muss geschrieben, gewartet und vor allem getestet werden, wer soll das denn bitte Deiner Ansicht nach machen? Die Gnome-Entwickler, von denen die große Mehrheit wahrscheinlich nicht einmal eine Maschine mit FreeBSD oder Solaris besitzt, und die sich für diese Systeme auch nicht interessieren?



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

  19. Re: Systemd statt Consolekit

    Autor: ChilliConCarne 29.02.12 - 07:58

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Was ist denn daran kompliziert, sich dem Problem anzunähern indem ich ein
    > paar print's platziere?
    Ein *paar* prints bei SysVInit?

    > Und die Kommentare im Quellcode erwecken auf
    > mich nicht den Eindruck, dass man fehlerfreie Software ausliefern will.
    Bitte? Nur mal ein Beispiel:
    http://cgit.freedesktop.org/systemd/systemd/tree/src/systemd/sd-daemon.h
    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?

  20. Re: Systemd statt Consolekit

    Autor: ChilliConCarne 29.02.12 - 08:16

    Auch wenn ich den Rechner nur einmal, höchstens zweimal täglich hoch bzw. runter fahre, finde ich das angenehm. Und ob du das jetzt für sinnvoll erachtest ist gar nicht der Punkt. Es geht *rein* darum, dass deine 'Vermutung' nicht stimmt.

  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 Programm-Management (m/w/d) für die unternehmensweite Einführung von Microsoft Dynamics ... (m/w/d)
    Bw Bekleidungsmanagement GmbH, Köln
  2. Projektmanager Innovation (m/w/d)
    ALDI International Services GmbH & Co. oHG, Mülheim an der Ruhr
  3. Senior Anwendungsentwickler (m/w/d) Depotbestand
    Deutsche WertpapierService Bank AG, Frankfurt am Main, Düsseldorf
  4. Java-Entwickler (m/w/d)
    e.bootis, Essen

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. 499,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de