Eine Aufteilung in auch von außen besser erkennbare Systemteile hätte sicher einen Großteil der Kritik beseitigt.
Ähnlich wie es bei GNOME gemacht wird. Ein großes Projekt, aber viele klar getrennte Teile, selbst wenn es die gleichen Entwickler sind. Dies schafft Transparenz und beseitigt Unklarheiten, bevor sie entstehen. Aber sie haben sich dagegen entschieden, und jetzt muss man dort eben auch mit der daraus entstehenden Kritik leben.
Das hätte man natürlich ändern können, aber Lennart Poettering bleibt sich da ja lieber selber treu
> Ähnlich wie es bei GNOME gemacht wird. Ein großes Projekt, aber viele klar getrennte Teile
Zu viel Kleinstückelung ist auch nicht gut, das war bei Gnome früher extremer. Bei Gnome 3 wurde da einiges konsolidiert, Bibliotheken zusammengefasst etc. Jede Shared Library, jede Abstraktionsschicht hat auch ihren Preis.
Sicherlich muss das Verhältnis stimmen. Ob journald jetzt wirklich Teil von systemd sein musste? Oder diverse der kleineren Dienste?
Sicherlich muss man systemd nicht in > 60 kleine Pakete zerteilen, nur weil es entsprechend viele binaries gibt, eine Gewisse Aufteilung hätte dem Ansehen des Projekts jedoch gut getan.
Nun hat das Ansehen seiner Arbeit Lennart Poettering wohl noch nie sooo sehr interessiert, oder zu einem Umdenken bewegt, jedoch hätte sich manche Kritik am Anfang verhindern lassen.
Die Frage sehe ich genau so. Und es wird noch verrückter. Ohne einen in Betrieb befindlichen journald "kommt das System nicht mehr hoch"!. Das habe ich bei Fedora 18 selbst getestet. Ich hatte den journald mit "mask" deaktiviert. Ein "disable" funktionierte erst gar nicht. Anschließend fuhr das System wahrscheinlich bis zu der Stelle auch, an der journald wohl aktiviert werden sollte. An meinen Äußerunge hört man wahrscheinlich auch heraus, daß die Fehlermeldungen so unverständlich sind, daß man nicht erkennen kann, wo der Fehler liegt.
Und die Geschichte mit dem journald hat mir den Boden aus dem Faß getrieben. So was brauche ich nicht, wo mir Dinge aufgezwungen werden und zwar in der Form, daß systemd nicht mehr funktioniert, wenn journald deaktiviert wird.
Sollte systemd wirklich bei allen Distributionen Standard werden, dann dürfte für mich wahrscheinlich nur noch Slackware in Betracht kommen -die werden bestimmt nicht sowas nicht mit machen aufgrund ihres KISS (keep it small and simple) Prinzips. Sollte ich mich diesbzgl. irren, lande ich mit an Sicherheit grenzender Wahrscheinlichkeit bei einem BSD-Derivat.
Von den Machern ist außer arroganten Äußerungen nichts anderes substantiiertes zu vernehmen. Das ist für mich auch schon ein Grund skeptisch zu sein. Wenn anstatt echten Argumenten nur Polemik gegen die Skeptiker geworfen wird.
"Sollte systemd wirklich bei allen Distributionen Standard werden, dann dürfte für mich wahrscheinlich nur noch Slackware in Betracht kommen"
Wie es scheint, bleibt Canonical sich relativ treu und wird wohl bis auf weiteres auf Upstart setzen. Einzelne Elemente werden wohl aus Systemd verwendet, jedoch nicht deren Init-Implementierung an sich.
Wie es scheint, bleibt Canonical sich relativ treu und wird wohl bis auf weiteres auf Upstart setzen. Einzelne Elemente werden wohl aus Systemd verwendet, jedoch nicht deren Init-Implementierung an sich.
Das wird wohl so sein, allerdings hat Canonical solche Entscheidungen doch quasi nie auf Grund technischer Überlegungen getroffen sondern eher auf Grund eines NIH-Komplexes.
Zumal man ja sicher einige Argumente gegen systemd auf den Weg bringen kann, aber sicher ist auch, dass Upstart wohl kaum die "technisch korrekte" Lösung sein ist.
Auch Upstart hat seine stärken. Aber lass uns nicht zu sehr in diese Richtung mit der Argumentation abdriften, viele Vorteile und Nachteile sind auch stark davon abhängig, wie man die Zukunft des Linux-Desktops sieht, sowie welche anderen Dienste und Prozesse man in einer Distribution erwartet. Weder Upstart noch Systemd sind Lösungen, die ohne Umfeld laufen. Diskutiert man also über die Features beider Systeme, muss man zwingend auch über das Umfeld diskutieren. Doch in diesem Punkt müssen wir hier passen, den niemand kann sicher sagen, wie Canonical, Red Hat und co. sich wirklich entwicklen. Aber erst die zukünftige Entwicklung macht klar, welche Lösung der bessere Idee ist.
Upstart ist, da dürften wir uns einig sein, eine eher bewusst kleiner gehaltene Lösung, die eher auf Interaktion mit bestehenden Systemen hin entwickelt wurde. Auch das macht es schwer es mit Systemd zu vergleichen, das bewusst mehr Arbeiten selbst erledigt, die es nicht erledigen müsste.
Zudem sollte man nicht ignorieren, das Canonical Upstart begonnen hat, als es noch kein Systemd gab. Man kann ihnen also hier nichts vorwerfen.
Upstart ist, da dürften wir uns einig sein, eine eher bewusst kleiner gehaltene Lösung, die eher auf Interaktion mit bestehenden Systemen hin entwickelt wurde.
Das stimmt natürlich, aber genau das ist ja auch Teil des Problems. Upstart ist in meinen Augen eher Patchwork für das bestehende System. Das kann, wenn man es gut und konsequent betreibt ganz ok funktionieren, aber in der Realität sieht das leider oft anders aus. Einen Schnitt zu machen und sysvinit hinter sich zu lassen war die richtige Entscheidung. Über die anderen Entscheidungen kann man sicher lange diskutieren, aber diese eine sollte eigentlich kein Thema mehr sein.
Zudem sollte man nicht ignorieren, das Canonical Upstart begonnen hat, als es noch kein Systemd gab. Man kann ihnen also hier nichts vorwerfen.
Ich würde Canonical auch nicht vorwerfen, dass sie mit Upstart begonnen haben, zumal sie ja im Endeffekt auch selbst wissen wollen was sie mit ihrer Zeit anfangen. (Wobei Upstart einer der Gründe war warum ich mich nicht mehr mit dieser Distribution beschäftige, da mir das ständig Probleme bereitet hat.) Was ich Canonical vorwerfe ist, dass sie beim Design der Lösung (meiner Meinung nach) einfach gepatzt haben, nicht konsequent genug waren. Evtl. muss man nicht so radikal wie systemd vorgehen (was sicher Vor- und Nachteile hat), aber nur an der Oberfläche kratzen bringt es auch nicht.
Das ist auch der Grund warum Gnome 3 nur unter Linux richtig funktioniert mit den meisten Funktionen. Da müssen sich die Entwickler nicht wundern, warum Forks und KDE4 so viel erfolgreicher sind.
Eine Aufteilung in auch von außen besser erkennbare Systemteile hätte sicher einen Großteil der Kritik beseitigt.
Ähnlich wie es bei GNOME gemacht wird. Ein großes Projekt, aber viele klar getrennte Teile, selbst wenn es die gleichen Entwickler sind. Dies schafft Transparenz und beseitigt Unklarheiten, bevor sie entstehen.
Aber sie haben sich dagegen entschieden, und jetzt muss man dort eben auch mit der daraus entstehenden Kritik leben.
Das hätte man natürlich ändern können, aber Lennart Poettering bleibt sich da ja lieber selber treu
> Ähnlich wie es bei GNOME gemacht wird. Ein großes Projekt, aber viele klar getrennte Teile
Zu viel Kleinstückelung ist auch nicht gut, das war bei Gnome früher extremer. Bei Gnome 3 wurde da einiges konsolidiert, Bibliotheken zusammengefasst etc. Jede Shared Library, jede Abstraktionsschicht hat auch ihren Preis.
Sicherlich muss das Verhältnis stimmen.
Ob journald jetzt wirklich Teil von systemd sein musste? Oder diverse der kleineren Dienste?
Sicherlich muss man systemd nicht in > 60 kleine Pakete zerteilen, nur weil es entsprechend viele binaries gibt, eine Gewisse Aufteilung hätte dem Ansehen des Projekts jedoch gut getan.
Nun hat das Ansehen seiner Arbeit Lennart Poettering wohl noch nie sooo sehr interessiert, oder zu einem Umdenken bewegt, jedoch hätte sich manche Kritik am Anfang verhindern lassen.
Die Frage sehe ich genau so. Und es wird noch verrückter. Ohne einen in Betrieb befindlichen journald "kommt das System nicht mehr hoch"!. Das habe ich bei Fedora 18 selbst getestet. Ich hatte den journald mit "mask" deaktiviert. Ein "disable" funktionierte erst gar nicht. Anschließend fuhr das System wahrscheinlich bis zu der Stelle auch, an der journald wohl aktiviert werden sollte.
An meinen Äußerunge hört man wahrscheinlich auch heraus, daß die Fehlermeldungen so unverständlich sind, daß man nicht erkennen kann, wo der Fehler liegt.
Und die Geschichte mit dem journald hat mir den Boden aus dem Faß getrieben. So was brauche ich nicht, wo mir Dinge aufgezwungen werden und zwar in der Form, daß systemd nicht mehr funktioniert, wenn journald deaktiviert wird.
Sollte systemd wirklich bei allen Distributionen Standard werden, dann dürfte für mich wahrscheinlich nur noch Slackware in Betracht kommen -die werden bestimmt nicht sowas nicht mit machen aufgrund ihres KISS (keep it small and simple) Prinzips. Sollte ich mich diesbzgl. irren, lande ich mit an Sicherheit grenzender Wahrscheinlichkeit bei einem BSD-Derivat.
Von den Machern ist außer arroganten Äußerungen nichts anderes substantiiertes zu vernehmen. Das ist für mich auch schon ein Grund skeptisch zu sein. Wenn anstatt echten Argumenten nur Polemik gegen die Skeptiker geworfen wird.
Fast bin ich geneigt meinen Kommentar
mit grummelnden Grüßen
zu beenden.
Wolfram
"Sollte systemd wirklich bei allen Distributionen Standard werden, dann dürfte für mich wahrscheinlich nur noch Slackware in Betracht kommen"
Wie es scheint, bleibt Canonical sich relativ treu und wird wohl bis auf weiteres auf Upstart setzen. Einzelne Elemente werden wohl aus Systemd verwendet, jedoch nicht deren Init-Implementierung an sich.
Zumal man ja sicher einige Argumente gegen systemd auf den Weg bringen kann, aber sicher ist auch, dass Upstart wohl kaum die "technisch korrekte" Lösung sein ist.
Auch Upstart hat seine stärken. Aber lass uns nicht zu sehr in diese Richtung mit der Argumentation abdriften, viele Vorteile und Nachteile sind auch stark davon abhängig, wie man die Zukunft des Linux-Desktops sieht, sowie welche anderen Dienste und Prozesse man in einer Distribution erwartet. Weder Upstart noch Systemd sind Lösungen, die ohne Umfeld laufen. Diskutiert man also über die Features beider Systeme, muss man zwingend auch über das Umfeld diskutieren. Doch in diesem Punkt müssen wir hier passen, den niemand kann sicher sagen, wie Canonical, Red Hat und co. sich wirklich entwicklen. Aber erst die zukünftige Entwicklung macht klar, welche Lösung der bessere Idee ist.
Upstart ist, da dürften wir uns einig sein, eine eher bewusst kleiner gehaltene Lösung, die eher auf Interaktion mit bestehenden Systemen hin entwickelt wurde. Auch das macht es schwer es mit Systemd zu vergleichen, das bewusst mehr Arbeiten selbst erledigt, die es nicht erledigen müsste.
Zudem sollte man nicht ignorieren, das Canonical Upstart begonnen hat, als es noch kein Systemd gab. Man kann ihnen also hier nichts vorwerfen.
Einen Schnitt zu machen und sysvinit hinter sich zu lassen war die richtige Entscheidung. Über die anderen Entscheidungen kann man sicher lange diskutieren, aber diese eine sollte eigentlich kein Thema mehr sein.Ich würde Canonical auch nicht vorwerfen, dass sie mit Upstart begonnen haben, zumal sie ja im Endeffekt auch selbst wissen wollen was sie mit ihrer Zeit anfangen. (Wobei Upstart einer der Gründe war warum ich mich nicht mehr mit dieser Distribution beschäftige, da mir das ständig Probleme bereitet hat.)
Was ich Canonical vorwerfe ist, dass sie beim Design der Lösung (meiner Meinung nach) einfach gepatzt haben, nicht konsequent genug waren. Evtl. muss man nicht so radikal wie systemd vorgehen (was sicher Vor- und Nachteile hat), aber nur an der Oberfläche kratzen bringt es auch nicht.
Finde ich auch ein Unding, zumal das Ding in 6 Tagen ganze 11 kB Speicher und 7.5s Rechenzeit gefressen hat. Das muss ich unbedingt deaktivieren!
Das ist auch der Grund warum Gnome 3 nur unter Linux richtig funktioniert mit den meisten Funktionen. Da müssen sich die Entwickler nicht wundern, warum Forks und KDE4 so viel erfolgreicher sind.