Tja solls geben, bei gegenteil wird ja auch gemotzt. Ext4 ist ein fortschritt zu Ext3...eine Evolution. Systemd ist eine Revolution, ob gut oder schlecht muss jeder selber entscheiden. Für mich will das tool zuviel, das technisch gesehen der log zu bootprozess gehört ist klar, aber das ich nun systemctl eingeben muss und die logs ein eigenes format haben, dass kotzt mich teilweise gewaltig an....aber hat eben auch seine vorteile.
Ja stimmt aber ich meinte auch den nebenaufwand, logs können nicht mehr so leicht als text kopiert werden und hunderte scripts müssen geändert werden, teilweise auch hinterherhinkende überwachungssoftware im code geändert werden. Aber eben das ist nicht die sache von systemd, im allgemeinen finde ich das system sehr gut, nur ich bin faul und will meine 10 Jahre alten bash flickereien nicht anschauen, vom meine Ada-code ganz zu scheigen
logs können nicht mehr so leicht als text kopiert werden
Das stimmt doch gar nicht. Journalctl gibt die Logs im gleichen Format aus wie messages.log, alternativ z.B. auch als JSON, und ist deutlich flexibler als vorher. Die Texte kannst du weiterhin mit allen gängigen Unix-Tools verarbeiten.
Ich glaube, das ist falsch. Was hindert dich daran, einen traditionellen syslogd als Backend for journald zu benutzen? So wird das zumindest bei Fedora (und ich glaube auch bei Arch+Suse) gemacht.
Damit merkst du von journald überhaupt nichts, wenn du nicht willst. /var/log/messages etc. existieren dann genauso wie vorher. Du hast exakt gar keinen Umstellungsaufwand.
Wie bitte das geht??? Ich nehme alles zurück wenn dem so ist! systemd alleine produziert logs im eigenen format die signiert, komprimiert unsw....werden können, coole sache, aber hat eben den auslese-direkt nachteil. Wenn man aber denn traditionellel rsyslog anhängen könnte....das wär/ist sehr elegant.
"aber das ich nun systemctl eingeben muss und die logs ein eigenes format haben, dass kotzt mich teilweise gewaltig an"
Habe ich früher auch mal so gesehen, aber Fedora 16/17 haben mich da "bekehrt":
1. 'service ... restart' funktioniert immer noch
2. Die Logs werden (bei Fedora) immer noch per default im syslog gespeichert, nur dass jetzt eben auch early boot dabei ist und mir journald auf Wunsch auch nur die Log-Einträge eines daemons geben kann.
Man kann sich sicherlich fragen, wie viel denn wirklich zum "init" gehört, da befindet sich systemd jetzt sicherlich in einer Grauzone. Aber aufgrund der bisherigen Erfolge und Verbesserungen, die systemd gebracht hat, bin ich zuversichtlich, dass die Entwickler schon richtig entscheiden werden.
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.
Tja solls geben, bei gegenteil wird ja auch gemotzt. Ext4 ist ein fortschritt zu Ext3...eine Evolution. Systemd ist eine Revolution, ob gut oder schlecht muss jeder selber entscheiden. Für mich will das tool zuviel, das technisch gesehen der log zu bootprozess gehört ist klar, aber das ich nun systemctl eingeben muss und die logs ein eigenes format haben, dass kotzt mich teilweise gewaltig an....aber hat eben auch seine vorteile.
"... aber dass ich nun den roten Fuchs statt das blaue e anklicken muss ..." Auf dem Level zu kritisieren ist schon ein bisschen flach.
Ja stimmt
aber ich meinte auch den nebenaufwand, logs können nicht mehr so leicht als text kopiert werden und hunderte scripts müssen geändert werden, teilweise auch hinterherhinkende überwachungssoftware im code geändert werden. Aber eben das ist nicht die sache von systemd, im allgemeinen finde ich das system sehr gut, nur ich bin faul und will meine 10 Jahre alten bash flickereien nicht anschauen, vom meine Ada-code ganz zu scheigen 
Das stimmt doch gar nicht. Journalctl gibt die Logs im gleichen Format aus wie messages.log, alternativ z.B. auch als JSON, und ist deutlich flexibler als vorher. Die Texte kannst du weiterhin mit allen gängigen Unix-Tools verarbeiten.
Ja sind aber nicht mehr OHNE journalclt auszulesen. Aber ja es ist flexibler aber erfordert trotzdem arbeit bei der anpassung.
Ich glaube, das ist falsch. Was hindert dich daran, einen traditionellen syslogd als Backend for journald zu benutzen? So wird das zumindest bei Fedora (und ich glaube auch bei Arch+Suse) gemacht.
Damit merkst du von journald überhaupt nichts, wenn du nicht willst. /var/log/messages etc. existieren dann genauso wie vorher. Du hast exakt gar keinen Umstellungsaufwand.
Es hindert mich nichts, aber man kann den journald nicht abstellen. Das loging kann man abstellen, aber der journald läuft trotzdem.
Da müsstest systemd ohne journal neu-bauen, ist aktuell bei mir imo so....aber lennard sagt ja selber dass das make-script viele switches hat
Wie bitte das geht??? Ich nehme alles zurück wenn dem so ist! systemd alleine produziert logs im eigenen format die signiert, komprimiert unsw....werden können, coole sache, aber hat eben den auslese-direkt nachteil. Wenn man aber denn traditionellel rsyslog anhängen könnte....das wär/ist sehr elegant.
Den aufwand hat man immer, das backend will ja angehängt werden
aber um vielfaches weniger.
PS: Nein bei Arch ist das bin-format std.
"aber das ich nun systemctl eingeben muss und die logs ein eigenes format haben, dass kotzt mich teilweise gewaltig an"
Habe ich früher auch mal so gesehen, aber Fedora 16/17 haben mich da "bekehrt":
1. 'service ... restart' funktioniert immer noch
2. Die Logs werden (bei Fedora) immer noch per default im syslog gespeichert, nur dass jetzt eben auch early boot dabei ist und mir journald auf Wunsch auch nur die Log-Einträge eines daemons geben kann.
Man kann sich sicherlich fragen, wie viel denn wirklich zum "init" gehört, da befindet sich systemd jetzt sicherlich in einer Grauzone. Aber aufgrund der bisherigen Erfolge und Verbesserungen, die systemd gebracht hat, bin ich zuversichtlich, dass die Entwickler schon richtig entscheiden werden.
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.