Ich finde es schon heftig, was da an Abeitsleistung für einen fork aufgewendet wird, nur wegen des blöden init-systems. Warum nicht im installer oder tasksel oder wo auch immer eine Abfrage hinzufügen, welches init-system installiert werden soll? Das sollte doch kein Hexenwerk sein und alle sind glücklich. Debian ist doch nicht auf ein init-system festgelegt.
Das würde eben nicht alle glücklich machen. Die VUAs und ihre Community sehen auch gesinnungsmäßig Debian auf dem falschen Ast. Auch eine Infrastruktur, die es ermöglicht, eine Änderung wie Systemd von 4 Entwicklern entscheiden zu lassen, wird stark kritisiert. Dass der gesanmte Korpus der Entwickler dann auch noch entschieden, es gebe nichts zu entscheiden [ http://www.pro-linux.de/news/1/21749/debian-entscheidet-dass-es-nichts-zu-entscheiden-gibt.html ] waren alle Sympathien verspielt.
Kern der Panik einiger ist wohl das systemd durch Abhängigkeiten (zum Beispiel so wie bei GNOME) zum Zwang werden könnte. Nur ist ist der sysvinit Zwang den sie in ihrem Fork aufbauen keinen einzigen deut besser und widerspricht eigentlich genauso allem was unter Linux seit Jahren üblicher usus ist.
Aber da sie ja nun einen eigenen Fork haben der mein Interessenfeld nicht mal ansatzweise berührt ist es mir eigentlich ziemlich Wurscht was sie machen. Nur befürchte ich das es nicht lange dauern wird bis sie wieder anfangen zum Upstream hochzuwettern weil dieser eventuell ihre Bemühungen nicht gebührend unterstützt.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 13. Jan 2015 um 14:31.
Die Entwickler, wohlgemerkt nicht die Anwender, haben entschieden, daß eine Abhängigkeit von "systemd" zulässig sein soll bzw. darüber gar nicht erst abgestimmt werden soll. Damit ist Debian faktisch auf ein einziges Init-System, nämlich "systemd" festgelegt.
Die Debian Entwickler wollen keine Pluralität. Und überhaupt wollen Sie bestimmen. Die Anwender, sollen nicht bekommen, was sie sich wünschen, sondern was die Entwickler in all ihrer Arroganz für ihn als nützlich entscheiden. Schöne neue Linux Welt.
Die Entwickler, wohlgemerkt nicht die Anwender, haben entschieden, daß eine Abhängigkeit von "systemd" zulässig sein soll bzw. darüber gar nicht erst abgestimmt werden soll.
Das ist meines Wissens so nicht richtig. Es wurde lediglich das wie bisher eine Abhängigkeit kein Kriterium für einen Auschluss aus der Distribution ist. Egal ob das Paket nun von sysvinit, systemd init, oder einem nicht-init Paket abhängt.
Der Paketabhängigkeitsmechanismus stellt ohnehin sicher, dass Pakete mit fehlenden Abhängigkeiten nicht installiert werden, bzw. Abhängigkeiten bei Aufforderung auch installiert werden.
Gibt es überhaupt schon Beispiele für Daemons, die von systemd als Init abhängen?
Die Debian Entwickler wollen keine Pluralität
Ah, Sarkasmus!
Aber ich lasse die Erklärung trotzdem mal stehen, die ungenauen Behauptungen liest man ja durchaus auch in erstgemeinten Kontexten.
Das _ist_ absolut richtig, wie Du selbst ausführst. Vlt. nicht vollständig, weil eine Abhänigkeit von einem bestimmten init-System, egal ob systemd, sysvinit o. a., geduldet wird.
Kein Sarkasmus, eine Feststellung. Mehr nicht. Eine Debian Eigenschaft. Unter den GNU/Linux Distributionen herrscht Pluralität. Zu Jessie wird es bald die Devuan Alternative geben.
Ich liebe die Freiheit! Das ist nunmal die Essenz von FOSS.
P.S. Ironie Ich dachte, Dein Beitrag wäre ernstgemeint /Ironie
Von da-real-lala am Di, 13. Januar 2015 um 22:11 #
Als jemand, der von init Systemen keine Ahnung hat, will ich das auch nicht entscheiden. Es sollen kompetente Personen machen. Ich finde das System in dem Sinne schon richtig.
Von .-,-.,.-,-.,-.,.-, am Di, 13. Januar 2015 um 22:37 #
Es gab zu Sysvinit-Zeiten vor Upstart nie Pluralität in Debian im Hinblick auf die Init-Systeme.
Debian wird ab Jessie+1 notgedrungen wieder an diese sinnvolle Tradition anknüpfen, schließlich wird kaum jemand alternative Init-Systeme in Debian in Zukunft pflegen.
Systemd in openSUSE funktioniert jedenfalls hervorragend. Sie haben dafür zwar ab 12.1 fünf Releases benötigt, bis sie soweit waren, sie haben es aber mit 13.2 endgültig geschafft.
Ich finde es im übrigen auch ziemlich nachteilig, dass neben Sysvinit auch KDE3 und Gnome2 nicht mehr in Debian sind. Gnome 1.2 und KDE 1.1.2 fand ich übrigens noch besser. Wer forkt und gibt uns armer Community wieder die GTK1- und Qt1-Desktops zurück? Jetzt aber forken, marsch, marsch!!!
Systemd ist ein Init-System. Alle Teile die mit dem Init System nichts zu tun haben sind in Daemone ausgelegt. Damit ist Systemd sehr modular und jeder kann Alternativen zu z.B. logind schreiben.
Von Anonymous Coward am Mi, 14. Januar 2015 um 03:05 #
Aktuelle Versionen von Logind laufen schon seit längerer Zeit nicht mehr ohne systemd, genau wie das journal und demnächst auch udevd (nach der Umstellung auf Kdbus).
Aber Hauptsache irgendeinen uninformierten Blödsinn geschrieben, einfach weil es so schön zum eigenen Weltbild passt.
Man kann es also nicht abstreiten, dass Abhängigkeiten bestehen. Nur stört das in der Praxis nur Ideologen.
Von .-,.-,.-,-.,-.,.-,.-,.-,.-, am Mi, 14. Januar 2015 um 15:56 #
Deine offensichtlich rein zufällige Art und Weise, bei Deinem letzten Posting in bestimmter Manier zu klicken, hat dieses Doppelposting ausgelöst. Offensichtlich konnten dabei auf Rezipientenseite die beiden zeitlich kaum unterschiedlichen, gleichen Postings nicht mehr als identisch identifiziert werden.
Deine offensichtlich rein zufällige Art und Weise, bei Deinem letzten Posting in bestimmter Manier zu klicken, hat dieses Doppelposting ausgelöst.
Dafür muss man nicht zufällig klicken, dass kann man ganz leicht nachvollziehen: Posting verfassen, absenden und mit dem 'Zurück-Button' im Browser einen Schritt zurück gehen. Schon gibt es ein Doppelposting.
Zurück und dann wieder vor. Klappt(e) zumindest mit qupzilla. Weitere Möglichkeit:
Wenn der pro-linux Server mal etwas träge ist und ich etwas ungeduldig mehrfach den 'Senden' Button drücke, dann habe ich hinterher für jeden Druck ein Posting ( ebenfalls qupzilla ).
Zurück und dann wieder vor. Klappt(e) zumindest mit qupzilla. Weitere Möglichkeit:
Wenn der pro-linux Server mal etwas träge ist und ich etwas ungeduldig mehrfach den 'Senden' Button drücke, dann habe ich hinterher für jeden Druck ein Posting ( ebenfalls qupzilla ).
Das liegt daran, dass der Affe der das hier programmiert hat vergessen hatte, jeder Nachricht eine ID mitzugeben. So können beliebige vielen Nachrichten mit gleichen Inhalt durch Mehrfachklick oder zurück versendet werden. Auch der Server prüft nicht ob die Nachrichten in die gleichen Sitzung auch unterschiedliche Hashes hat. Unterm Strich, die Software ist seit Jahren kaputt und daran möchte man auch nix ändern.
Nochmals danke für Eure Antworten. Dadurch wird einiges klarer.
Die Bemerkung mit dem "Affen" hilft aber leider nicht wirklich weiter. Fast wären wir hier richtig konstruktiv geworden.
Derjenige, der die Anwendung programmiert hat, muss die Fehlerbehebung aber leider komplett in Eigenregie durchführen oder durchführen lassen, da - soweit mir bekannt - der Sourcecode dieser Anwendung nicht bekannt ist. Allzu schwierig sollte das aber nicht sein. Das geht mich aber logischerweise nichts an.
Viel wichtiger ist, dass man hier auf pro-linux.de ohne Registrierung posten darf.
Wie kommunizieren denn sonst die abhängigen Daemons miteinander? Selbst lauffähig sind die ja nicht. Bisher gibts kein Daemon was die Aufgabe von Systemd übernehmen könnte und könnte man Systemd ohne pid=1 betreiben, dann bräuchten wir nicht das Gefrickel um die ganzen Schnittstellen in den GUIs zu ersetzen. Systemd baut bald auf KDBUS aus, damit wird Dbus langfristig weichen müssen da doppelte Funktionalität. Und Ressourcenhandling wird doch auch schon nur über Systemd und dessen Daemons erledigt.
Wie kommunizieren denn sonst die abhängigen Daemons miteinander? Selbst lauffähig sind die ja nicht.
Hat das irgendwer behauptet? Klar muß der Hauptdaemon laufen, aber PID 1 muss er nur sein, wenn er die Aufgaben von Init übernimmt.
Ob man systemd als Init, über sysvinit oder Upstart startet spielt für diese anderen Dienste keine Rolle.
Systemd baut bald auf KDBUS aus, damit wird Dbus langfristig weichen müssen da doppelte Funktionalität.
Das sind zwei verschieden Paar Schuhe. KDBUS ersetzt den dbus-daemon, die Komponente, die den Bus bereitstellt. D-Bus, als IPC Mechanismus, ist davon nicht betroffen. Für Anwendungen ist die Art der Busbereitstellung transparent.
Also wer Debian wirklich "forken" will, der verdient entweder den Preis für die höchste Selbstüberschätzung seit Anbeginn der Zeit oder den absoluten Respekt wenn er das schafft
sich veteran unix admin zu nennen finde ich peinlich. und dann noch militärsprache?
immer noch besser als vegan unix admin.
oder vatikan unix admin. killall daemon
nö, nicht besser.
veteran heißt einfach nur erfahren bzw. altgedient. Von einem "combat veteran" war nicht die Rede.
veteran kommt ganz klar aus dem militärischen sprachgebrauch und wurde mit der zeit hier und da auf den zivilen bereich übertragen.
Man sollte einfach der englischen Sprache mächtig sein, bevor man hier Müll absondert.
Eine "senior engineer" ist auch kein "alter Knacker"!
Ich finde es schon heftig, was da an Abeitsleistung für einen fork aufgewendet wird, nur wegen des blöden init-systems. Warum nicht im installer oder tasksel oder wo auch immer eine Abfrage hinzufügen, welches init-system installiert werden soll? Das sollte doch kein Hexenwerk sein und alle sind glücklich. Debian ist doch nicht auf ein init-system festgelegt.
Das würde eben nicht alle glücklich machen. Die VUAs und ihre Community sehen auch gesinnungsmäßig Debian auf dem falschen Ast. Auch eine Infrastruktur, die es ermöglicht, eine Änderung wie Systemd von 4 Entwicklern entscheiden zu lassen, wird stark kritisiert. Dass der gesanmte Korpus der Entwickler dann auch noch entschieden, es gebe nichts zu entscheiden [ http://www.pro-linux.de/news/1/21749/debian-entscheidet-dass-es-nichts-zu-entscheiden-gibt.html ] waren alle Sympathien verspielt.
Kern der Panik einiger ist wohl das systemd durch Abhängigkeiten (zum Beispiel so wie bei GNOME) zum Zwang werden könnte. Nur ist ist der sysvinit Zwang den sie in ihrem Fork aufbauen keinen einzigen deut besser und widerspricht eigentlich genauso allem was unter Linux seit Jahren üblicher usus ist.
Aber da sie ja nun einen eigenen Fork haben der mein Interessenfeld nicht mal ansatzweise berührt ist es mir eigentlich ziemlich Wurscht was sie machen. Nur befürchte ich das es nicht lange dauern wird bis sie wieder anfangen zum Upstream hochzuwettern weil dieser eventuell ihre Bemühungen nicht gebührend unterstützt.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 13. Jan 2015 um 14:31.Diese Abhängigkeiten setzen aber nur systemd als Dienst vorraus, nicht als init.
Die Entwickler, wohlgemerkt nicht die Anwender, haben entschieden, daß eine Abhängigkeit von "systemd" zulässig sein soll bzw. darüber gar nicht erst abgestimmt werden soll. Damit ist Debian faktisch auf ein einziges Init-System, nämlich "systemd" festgelegt.
Die Debian Entwickler wollen keine Pluralität. Und überhaupt wollen Sie bestimmen. Die Anwender, sollen nicht bekommen, was sie sich wünschen, sondern was die Entwickler in all ihrer Arroganz für ihn als nützlich entscheiden. Schöne neue Linux Welt.
Das ist meines Wissens so nicht richtig.
Es wurde lediglich das wie bisher eine Abhängigkeit kein Kriterium für einen Auschluss aus der Distribution ist. Egal ob das Paket nun von sysvinit, systemd init, oder einem nicht-init Paket abhängt.
Der Paketabhängigkeitsmechanismus stellt ohnehin sicher, dass Pakete mit fehlenden Abhängigkeiten nicht installiert werden, bzw. Abhängigkeiten bei Aufforderung auch installiert werden.
Gibt es überhaupt schon Beispiele für Daemons, die von systemd als Init abhängen?
Ah, Sarkasmus!
Aber ich lasse die Erklärung trotzdem mal stehen, die ungenauen Behauptungen liest man ja durchaus auch in erstgemeinten Kontexten.
Das _ist_ absolut richtig, wie Du selbst ausführst. Vlt. nicht vollständig, weil eine Abhänigkeit von einem bestimmten init-System, egal ob systemd, sysvinit o. a., geduldet wird.
Kein Sarkasmus, eine Feststellung. Mehr nicht. Eine Debian Eigenschaft. Unter den GNU/Linux Distributionen herrscht Pluralität. Zu Jessie wird es bald die Devuan Alternative geben.
Ich liebe die Freiheit! Das ist nunmal die Essenz von FOSS.
P.S. Ironie Ich dachte, Dein Beitrag wäre ernstgemeint /Ironie
> Beispiele
http://i.imgur.com/SxufNQ2.png
von http://lwn.net/Articles/617850/
Deswegen brauchts das shim.
Das sind Paketabhängigkeiten, d.h. sie zeigen welche Pakete systemd installiert brauchen, nicht welche Programme systems als Init brauchen.
Alle damit zufriedenen Programme sind auch mit systemd zufrieden wenn es nicht als Init läuft.
Insofern praktisch Gegenbeispiele.
Als jemand, der von init Systemen keine Ahnung hat, will ich das auch nicht entscheiden. Es sollen kompetente Personen machen. Ich finde das System in dem Sinne schon richtig.
Es gab zu Sysvinit-Zeiten vor Upstart nie Pluralität in Debian im Hinblick auf die Init-Systeme.
Debian wird ab Jessie+1 notgedrungen wieder an diese sinnvolle Tradition anknüpfen, schließlich wird kaum jemand alternative Init-Systeme in Debian in Zukunft pflegen.
Systemd in openSUSE funktioniert jedenfalls hervorragend. Sie haben dafür zwar ab 12.1 fünf Releases benötigt, bis sie soweit waren, sie haben es aber mit 13.2 endgültig geschafft.
Ich finde es im übrigen auch ziemlich nachteilig, dass neben Sysvinit auch KDE3 und Gnome2 nicht mehr in Debian sind. Gnome 1.2 und KDE 1.1.2 fand ich übrigens noch besser. Wer forkt und gibt uns armer Community wieder die GTK1- und Qt1-Desktops zurück? Jetzt aber forken, marsch, marsch!!!
Die Entwickler haben ja auch die Arbeit damit, während Du Dich in Deinen vorgewärmten Sessel hockst und rumnölst.
> nur wegen des blöden init-systems
Systemd ist kein Init-System und genau das ist das Problem.
Systemd ist ein Init-System. Alle Teile die mit dem Init System nichts zu tun haben sind in Daemone ausgelegt. Damit ist Systemd sehr modular und jeder kann Alternativen zu z.B. logind schreiben.
> in Daemone ausgelegt
Die systemd als pid 1 voraussetzen.
So ein Blödsinn. Ubuntu benutzt viele Teile des systemd-Stacks (Wie z.B. logind) zusammen mit Upstart.
Aber Hauptsache irgendeinen uninformierten Blödsinn geschrieben, einfach weil es so schön zum eigenen Weltbild passt.
Aktuelle Versionen von Logind laufen schon seit längerer Zeit nicht mehr ohne systemd, genau wie das journal und demnächst auch udevd (nach der Umstellung auf Kdbus).
Man kann es also nicht abstreiten, dass Abhängigkeiten bestehen. Nur stört das in der Praxis nur Ideologen.
Was ist eigentlich mit ProLinux los? Immer diese dummen Doppelposts!!!
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 13. Jan 2015 um 21:12.Deine offensichtlich rein zufällige Art und Weise, bei Deinem letzten Posting in bestimmter Manier zu klicken, hat dieses Doppelposting ausgelöst. Offensichtlich konnten dabei auf Rezipientenseite die beiden zeitlich kaum unterschiedlichen, gleichen Postings nicht mehr als identisch identifiziert werden.
Dafür muss man nicht zufällig klicken, dass kann man ganz leicht nachvollziehen: Posting verfassen, absenden und mit dem 'Zurück-Button' im Browser einen Schritt zurück gehen. Schon gibt es ein Doppelposting.
Ich teste das einmal.
Das klappt so nicht.
Wie lautet die vollständige Anleitung?
Sehr wahrscheinlich hast Du nach dem Zurückgehen nochmals auf Abschicken geklickt?
Zurück und dann wieder vor. Klappt(e) zumindest mit qupzilla. Weitere Möglichkeit:
Wenn der pro-linux Server mal etwas träge ist und ich etwas ungeduldig mehrfach den 'Senden' Button drücke, dann habe ich hinterher für jeden Druck ein Posting ( ebenfalls qupzilla ).
Zurück und dann wieder vor. Klappt(e) zumindest mit qupzilla. Weitere Möglichkeit:
Wenn der pro-linux Server mal etwas träge ist und ich etwas ungeduldig mehrfach den 'Senden' Button drücke, dann habe ich hinterher für jeden Druck ein Posting ( ebenfalls qupzilla ).
Posting senden, Zurück-Button drücken, danach den Vor-Button und schon habe ich ein Doppelposting. Wie Du siehst, klappt das immer noch.
Dumm nur, dass mir das auch ohne Zurück-Button passiert:
Posting senden, warten, Doppelpost.
Das liegt daran, dass der Affe der das hier programmiert hat vergessen hatte, jeder Nachricht eine ID mitzugeben. So können beliebige vielen Nachrichten mit gleichen Inhalt durch Mehrfachklick oder zurück versendet werden. Auch der Server prüft nicht ob die Nachrichten in die gleichen Sitzung auch unterschiedliche Hashes hat.
Unterm Strich, die Software ist seit Jahren kaputt und daran möchte man auch nix ändern.
Nochmals danke für Eure Antworten. Dadurch wird einiges klarer.
Die Bemerkung mit dem "Affen" hilft aber leider nicht wirklich weiter. Fast wären wir hier richtig konstruktiv geworden.
Derjenige, der die Anwendung programmiert hat, muss die Fehlerbehebung aber leider komplett in Eigenregie durchführen oder durchführen lassen, da - soweit mir bekannt - der Sourcecode dieser Anwendung nicht bekannt ist. Allzu schwierig sollte das aber nicht sein. Das geht mich aber logischerweise nichts an.
Viel wichtiger ist, dass man hier auf pro-linux.de ohne Registrierung posten darf.
Exakt, genauso wie sie auch einen Kernel zum Laufen brauchen. Und in der echten Welt interessiert das auch keinen.
Bist du dir da sicher?
So weit ich weiß setzt nicht mal der Hauptdaemon von systemd PID 1 voraus.
Welche Kernelfunktionalität ist nur für PID 1 zugänglich?
Wie kommunizieren denn sonst die abhängigen Daemons miteinander? Selbst lauffähig sind die ja nicht. Bisher gibts kein Daemon was die Aufgabe von Systemd übernehmen könnte und könnte man Systemd ohne pid=1 betreiben, dann bräuchten wir nicht das Gefrickel um die ganzen Schnittstellen in den GUIs zu ersetzen. Systemd baut bald auf KDBUS aus, damit wird Dbus langfristig weichen müssen da doppelte Funktionalität. Und Ressourcenhandling wird doch auch schon nur über Systemd und dessen Daemons erledigt.
Hat das irgendwer behauptet?
Klar muß der Hauptdaemon laufen, aber PID 1 muss er nur sein, wenn er die Aufgaben von Init übernimmt.
Ob man systemd als Init, über sysvinit oder Upstart startet spielt für diese anderen Dienste keine Rolle.
Das sind zwei verschieden Paar Schuhe.
KDBUS ersetzt den dbus-daemon, die Komponente, die den Bus bereitstellt.
D-Bus, als IPC Mechanismus, ist davon nicht betroffen.
Für Anwendungen ist die Art der Busbereitstellung transparent.
Also wer Debian wirklich "forken" will, der verdient entweder den Preis für die höchste Selbstüberschätzung seit Anbeginn der Zeit oder den absoluten Respekt wenn er das schafft
Gibts das immernoch? Ich dachte dieser schwachsinnige Trollversuch ist schon verschwunden.