naja, "benutzt" wurde es eigentlich recht wenig. RHEL6 startet nur das mit upstart, was frueher in /etc/inttab stand (getty u.ae). Services wurden nie ueber upstart gestartet.
IMO lag das an der Fehlkonzeption von Upstart, dass es keinen Mechanismus gab (gibt?), Dienste zu aktivieren bzw. deaktivieren (ala "systemctl enable/disable service").
In upstart musste (muss?) das durch Manipulation einer komplexen "start on" Zeile geschehen, was nicht der RH Weg ist.
Die Fehlkonzeption von Upstart (und übrigens auch von OpenRC) war eigentlich eher, dass man so nahe wie möglich am alten System bleiben wollte. Das was du schreibst ist ja im Endeffekt auch eine Folge genau davon. Dazu kommt, dass man das Problem der Abhängigkeiten zwischen Services (die eben zweifelsohne existieren) eigentlich ignorieren wollte (und auch eine gewisse Zeit ignoriert hat), wobei es meines Wissens inzwischen gelöst ist.
Ein Auto wird eben auch nie wirklich gut fliegen können, nur weil ich 2 Flügel dran schraube. Wenn man es gut macht kann es funktionieren, aber manchmal ist es eben auch sinnvoller das gesamte Konzept zu überdenken. Genau das hat dann letztendlich erst systemd gemacht. In manchen Teilen ist systemd evtl. über das Ziel hinaus geschossen, aber das ist dann wieder eine andere Diskussion.
"Die Fehlkonzeption von Upstart (und übrigens auch von OpenRC) war eigentlich eher, dass man so nahe wie möglich am alten System bleiben wollte."
Ohne Zweifel ein Problem, aber ein nachvollziehbares. Immerhin hatte es vorher kein radikales neues System geschaff sich durchzusetzen.
Vor systemd hätte doch niemand ernsthaft geglaubt, das ein Wechsel möglich wäre. Auch jetzt geht es nur, weil Red Hat voll dahinter steht. Würde Red Hat "no" sagen, hätten alle ein Problem. Für viele ist Red Hat eben das maß aller Dinge für solche Entscheidungen.
Hier ist Canonical etwas der geschundene: Sie durften ausloten wie Weit die Akzeptanz geht für einen Init-Ersatz. Als klar war das alle bereit sind, hat Red Hat etwas eigenes gebaut. Erst durch Upstart wurde aber klar, wie weit man die Neuentwicklung treiben konnte.
Sicherlich hat Canonical auch etwas zu zaghaft reagiert, aber Lennart Poettering war nun - so mein Eindruck - auch nicht gerade dabei, dort hin eine Hand zu reichen.
Ohne Zweifel ein Problem, aber ein nachvollziehbares. Immerhin hatte es vorher kein radikales neues System geschaff sich durchzusetzen.
Das ist schon völlig richtig, aber das heißt im Endeffekt eins: Es hätte immer wieder neue Versuche gegeben, alternative Init-Systeme zu etablieren, so lange "nur" Upstart auf dem Markt war.
Das soll Upstart auch gar nicht abwerten, man muss ja Canonical zu Gute halten, dass sie zumindest versucht haben, Init zeitgemäßer zu gestalten. Man hätte aber durchaus auch damit rechnen müssen, dass so etwas passiert, wenn man eben nur den halben Weg geht.
Hier ist Canonical etwas der geschundene: Sie durften ausloten wie Weit die Akzeptanz geht für einen Init-Ersatz. Als klar war das alle bereit sind, hat Red Hat etwas eigenes gebaut. Erst durch Upstart wurde aber klar, wie weit man die Neuentwicklung treiben konnte.
Sicherlich hat Canonical auch etwas zu zaghaft reagiert, aber Lennart Poettering war nun - so mein Eindruck - auch nicht gerade dabei, dort hin eine Hand zu reichen.
Man könnte sogar noch weiter gehen und behaupten, dass systemd ohne Upstart nicht so weit wäre wie es heute ist. Bestes Beispiel ist hier doch HAL. Das Konzept war sicher interessant, aber schon recht bald war klar, dass dieser radikale Ansatz auch wieder abgelöst werden würde.
Im Grunde war Upstart also der Versuch für die Tonne (sorry @ Canonical, aber in meinen Augen ist es so), den es aber ein Stück weit auch einfach gebraucht hat.
> Würde Red Hat "no" sagen, hätten alle ein > Problem. Für viele ist Red Hat eben das maß > aller Dinge für solche Entscheidungen.
Würde Debian zu systemd "no" sagen, hätten auch viele ein Problem. Es tun ja schon massenweise Idividuen aufmüpfen, weil sie systemd einfach nur hassen.
Wieso machen wir eigentlich keinen Fork von Systemd fuer alle unixes? Achso ihr habt auch keine Zeit dafuer....wie gross waehre denn der arbeitsaufwand?
Tun WIR das??? Was willst du damit sagen? Es hat ja auch niemand um Linux gebeten, wenn du keine bessere loesung hast wird halt die scheinbar beste genommen, mit deiner einstellung wird es genau so sein wie andere es wollen...aber sicher nicht genau so wie du es willst...das wirst vom mitmachen nicht verschont.
PS: Ich fand die entwicklung des Rad schon scheisse, das gibt nur stress und zeitdruck und die uebrigen sklaven pluecken nun orangen in suedspanien, eine Pyramide ist da schon sinvoller.
> Kennst du diesen Spruch "Hallo, ich bin der Neue" und dann gabs mächtig beef
Genau so kommt mir die Linux Community aktuell vor. Es wird wahllos auf alles neue eingedroschen, egal worum es geht und ohne vorher zu schauen ob das Neue vielleicht Vorteile bringt oder alte Probleme löst. Nö, alles Neue ist erstmal Mist - nachher muss man noch alte Gewohnheiten ablegen oder liebgewonnene Workarounds beseitigen.
Es geht nicht immer um das "Technologische" sondern auch um das "Politische". Das technologisch Beste kann u.U. eine politische Katastrophe bedeuten. Die noch nicht absehbaren Folgeerscheinungen sind außen vor. Daher sollte man mit Bedacht vorgehen und ggf. einen Mittelweg mit alternativer Technologie fahren. Debian macht das ganz richtig. Man denkt vorher etliche - nicht alle - Szenarien durch und entscheidet dann anhand der gesammelten Erkennntisse. Dies hätte ich mir von anderen Distributionen auch gewünscht, bevor sie "blind" auf "systemd" aufsprangen.
Es geht mir vor allem um die Formulierung im Text, nicht so sehr wie weit Red Hat wirklich upstart genutzt hat, oder ob man upstart für passend hält. Der Text hat einfach an der genannten Stelle unnötig eine Wertung eingebracht, die gleichwohl für die Konkurrenten nicht gebraucht wurde, obwohl sie alle das gleiche Vorgehen haben. Sicherlich ist es nicht nur mein Eindruck, das nur deswegen von "Alleingang" gesprochen wird, weil es Canonical ist. Wäre Red Hat gerade an dieser Stelle, wäre keine solche Formulierung benutzt worden. Ich kann mich auch an keinen solchen Fall erinnern, als systemd neu war, und upstart schon Verbreitung gefunden hatte (in den News, nicht in den Kommentaren).
Zumal das weiter Nutzen einer Lösung, die auch andere gebrauchten, als "Alleingang" nicht wirklich fair bezeichnet ist. Zumal upstart, als es zuerst eingesetzt wurde, eine von vielen Seiten willkommene Entwicklung war.
Nur weil Canonical nicht auf den ersten nächsten Zug aufspringt, sie dafür zu schelten, muss das sein?
Es kann mir keiner erzählen, das eine solche Formulierung ein versehen ist. Zumal es bei Gentoo dann nett als "Gentoo entwickelte OpenRC" formuliert ist. Wir haben also im Satz 2x entwicklungen, und einen Alleingang. Bravo...
Zumal upstart, als es zuerst eingesetzt wurde, eine von vielen Seiten willkommene Entwicklung war.
Das stimmt, aber wenn man es genau betrachtet ist es doch so: 1. Canonical entwickelt im Alleingang Upstart 2. Andere (u.a. Novell und Red Hat) springen auf den Zug auf 3. Red Hat entwickelt im Alleingang systemd 4. Viele wechseln auf systemd 5. Unter den Distributionen, die neu veröffentlicht werden setzt eigentlich nur noch Ubuntu auf Upstart, insofern kann man in Zukunft durchaus wieder von einem Alleingang sprechen
Nur weil Canonical nicht auf den ersten nächsten Zug aufspringt, sie dafür zu schelten, muss das sein?
Muss man selbstverständlich nicht. Ich glaube es haben auch nicht wirklich viele damit ein Problem, dass Upstart weiter in Ubuntu verwendet werden soll. Problematisch wird es ja erst dann, wenn man seitens Canonical versucht Einfluss auf andere Distributionen (hier Debian) zu nehmen. Dann gibt es natürlich Knatsch, auch wenn man das seitens Canonical verstehen kann. Natürlich versuchen sie ihre Lösung in Debian unterzubringen, welches ja im Endeffekt die Basis für Ubuntu stellt.
Was die anderen Distributionen angeht kann man aber schon verstehen, dass sich immer mehr in Richtung systemd bewegen, denn neben den technischen Vorteilen muss man auch neidlos anerkennen, dass systemd mehr zur Vereinheitlichung der Linux-Platform beigetragen hat als die LSB das jemals vermocht hat. Was gab es früher einen Wildwuchs an Konfigurationsdateien, Verzeichnisstrukturen etc... Hier hat systemd endlich mal zum Teil Abhilfe geschaffen. Nicht immer zur Zufriedenheit alle (siehe Diskussion um /usr), aber eben doch effektiv.
Seitens Canonical kann man sich aber zumindest damit trösten, dass der "Zug" zumindest nie abgefahren sein, denn ein Wechsel auf systemd ist im Endeffekt fast von heute auf morgen möglich.
Es kann mir keiner erzählen, das eine solche Formulierung ein versehen ist. Zumal es bei Gentoo dann nett als "Gentoo entwickelte OpenRC" formuliert ist.
Was meines Wissens noch nicht mal ganz richtig ist. OpenRC wird inzwischen von Gentoo weiterentwickelt, aber seine Ursprünge hat es so weit mir bekannt außerhalb von Gentoo. Ich meine mich sogar zu erinnern, dass das Ziel damals eher die BSD Platform war, aber auf Grund der Konzeption (braucht nur eine POSIX Shell) dann natürlich auch auf Linux lief. Da der Entwickler ursprünglich bei Gentoo war war es auch in vielen Punkten eng an Gentoos damaliger Ausführung von Init angelehnt, so dass eine Migration sich anbot. Dazu kommt dann natürlich, dass Gentoo (wie viele andere Distributionen) unter dem NIH-Syndrom leidet (was man auch verstehen kann, wenn viel Zeit in einen gewissen Teil der Distribution investiert wurde), ist es schon verständlich, dass man daran festhält, auch wenn es sicher unter Gentoo recht einfach ist, OpenRC durch systemd zu ersetzen. (Vermutlich auch deutlich einfacher als unter Ubuntu Upstart zu ersetzen.)
"Das stimmt, aber wenn man es genau betrachtet ist es doch so: 1. Canonical entwickelt im Alleingang Upstart 2. Andere (u.a. Novell und Red Hat) springen auf den Zug auf 3. Red Hat entwickelt im Alleingang systemd 4. Viele wechseln auf systemd"
Bis hierhin stimme ich zu.
"5. Unter den Distributionen, die neu veröffentlicht werden setzt eigentlich nur noch Ubuntu auf Upstart, insofern kann man in Zukunft durchaus wieder von einem Alleingang sprechen"
Hier aber nicht :) Mein Problem ist, das die Linuxwelt sich noch nicht geschlossen für eine Richtung entschieden hat. Upstart hat - absolut ohne Zweifel - viel an Boden verloren. Aber noch immer ist es eine normale und auch außerhalb genutzte Lösung, die Canonical natürlich nicht einfach fallen lässt. Es gibt noch immer Distries (vor allem Debian), wie sich nicht entschieden haben. In einem solchen Umfeld halte ich die Bezeichnung für nicht passen, ja unfair.
Nun müsste eine Seite wie PL nicht unbedingt fair sein, eigene Meinungen sind erlaubt, auch bei News. Aber normalerweise ist PL relativ neutral, und dann sollte es dies durchgehend sein, das wäre angemessen.
Wenn einmal 99% der anderen Distries systemd nutzen (falls es so kommt), und Canonical würde Stur und mit vielen Nachteilen weiter upstart nutzen, dann wäre es sicher ein Alleingang. Aber aktuell ist Systemd optional, bringt noch kaum echte Vorteile, andere Distries sind unentschlossen oder nutzen auch mal upstart (auch mobil gibts ein paar Geräte, die das tun) usw.
Es ist einfach nicht der Moment, um von einem Alleingang zu reden. Wir sind an der Schwelle zur Entscheidung. a) Alle nutzen systemd b) Systemd und upstart werden parallel genutzt.
ein "c) nur upstart" ist unwahrscheinlich, das ist mit Red Hat nicht zu machen. Sonst hätten wir alle heute auch das Debian Format im Einsatz ;D
Von Anonymous Coward am Fr, 3. Januar 2014 um 02:13 #
Mein Problem ist, das die Linuxwelt sich noch nicht geschlossen für eine Richtung entschieden hat. Upstart hat - absolut ohne Zweifel - viel an Boden verloren. Aber noch immer ist es eine normale und auch außerhalb genutzte Lösung, die Canonical natürlich nicht einfach fallen lässt.
Ach wirklich? So wie ich das sehe sind Ubuntu und seine Derivate die einzigen Distributionen, die noch upstart verwenden. Gut, RHEL und SLES könnte man noch nennen, aber da steht auch schon fest, dass das jeweils nächste Release (RHEL 7 bzw. SLES 12) systemd verwenden wird.
"Was die anderen Distributionen angeht kann man aber schon verstehen, dass sich immer mehr in Richtung systemd bewegen, denn neben den technischen Vorteilen muss man auch neidlos anerkennen, dass systemd mehr zur Vereinheitlichung der Linux-Platform beigetragen hat als die LSB das jemals vermocht hat. Was gab es früher einen Wildwuchs an Konfigurationsdateien, Verzeichnisstrukturen etc... Hier hat systemd endlich mal zum Teil Abhilfe geschaffen. Nicht immer zur Zufriedenheit alle (siehe Diskussion um /usr), aber eben doch effektiv."
Das mag alles stimmen. Nur, was machen wir damit:
"Systemd ist derzeit nur auf Linux-Systemen einsetzbar und somit für die Debian-Architekturen kFreeBSD und Hurd nicht verfügbar, da deren Kernel keine cgoups unterstützen. Ein weiterer Kritikpunkt ist, dass Systemd bei aller technischen Überlegenheit das alte Unix-Prinzip des »one tool for the job« völlig außer Acht läßt und außer dem Systemstart mit Journal und Logind weitere Systemverwaltungsaufgaben übernimmt."
Unter dem Gesichtspunkt halte ich eine Diskussion über die "Alleingänge" von Ubuntu oder Red Hat für unsinnig.
Bei ersterem Problem muß Debian ein Problem lösen, dass viele andere Distributionen gar nicht haben.
Und diese Probleme einfach wegzudiskutieren scheint ja wohl kaum möglich zu sein.
Bei ersterem Problem muß Debian ein Problem lösen, dass viele andere Distributionen gar nicht haben.
Das ist schon richtig und darüber machen sie sich ja auch viele Gedanken. Verstehen kann ich hier allerdings nicht, weshalb man darauf besteht auf allen Platformen das gleiche Initsystem zu haben. systemd für Debian GNU/Linux zu adaptieren dürfte relativ wenig Aufwand mit sich bringen, da die meisten Teile von systemd auch so schon distributionsübergreifend verwendet werden können. Eine Portierung von systemd auf die genannten Architekturen kann man aber wohl ausschließen. Also kommen nur noch Upstart (welches evtl. auch portiert werden müsste) und OpenRC (welches bereits verfügbar ist) in Frage.
Ich sehe das daher so: Debian sollte für Linux systemd verwenden (oder upstart, wenn sie denn unbedingt wollen) und für die beiden anderen Architekturen OpenRC. Systemspezifische Lösungen wird es ohnehin immer geben, man wird nie alle 3 komplett unter einen Hut bringen können. Upstart oder systemd zu portieren halte ich nur dann (und auch wirklich nur dann) für sinnvoll, wenn andere BSD Distributoren (i.e. FreeBSD oder NetBSD) ein ernsthaftes Interesse daran haben und mithelfen.
Was den zweiten Teil angeht:
Ein weiterer Kritikpunkt ist, dass Systemd bei aller technischen Überlegenheit das alte Unix-Prinzip des »one tool for the job« völlig außer Acht läßt und außer dem Systemstart mit Journal und Logind weitere Systemverwaltungsaufgaben übernimmt.
Das stimmt so einfach nicht. Natürlich bringt systemd eine Reihe Tools in einem Paket mit, aber das macht z.B. coreutils auch. Oder kde-workspace. Da hat sich auch niemand beschwert, zumindest nicht mit diesem Argument. (Bei KDE kommt immer mal wieder die Frage nach den Abhängigkeiten und dem Umfang auf, aber das Zusammenfassen selbst wird nicht in Frage gestellt.)
Genauer gesagt gibt es hier 2 Aspekte: 1. Distributive Seite: Nicht wirklich ein Problem. Wie ich bereits erwähnte ist die Kompilierzeit für das komplette systemd Paket inkl. logind, journald, udev etc. gering. Ob 3 oder 4 Minuten spielt wirklich keine Rolle. Für Binärdistributionen kann man das Ergebnis einfach in verschiedene Teile aufspalten. Das wird bei Debian ja ohnehin auch so geplant. Z.B. logind und udev soll in jedem Fall verwendet werden, auch wenn Upstart das init wird. Für Sourcedistributionen ist es etwas schwieriger, aber angesichts der kurzen Kompilierzeit auch nicht schlimm. Ok, es nimmt ein bisschen Platz auf der HDD weg, wenn man noch Binaries rumliegen hat, die man nicht braucht, aber wenn es nach dem Gesichtspunkt geht, dann gibt es sicher hunderte anderer Beispiele, die wesentlich gravierender sind. 2. Technische Seite: Ich hab mir den Sourcecode jetzt nicht im Detail angeschaut, aber soweit ich das sehen kann, sind die Tools sauber getrennt. Wenn man es genauer betrachtet, erfüllt journald z.B. sogar wesentlich präziser die genannten Anforderungen, nämlich 1(!) Tool für Loggingzwecke (bzw. 2, wenn man journald und journalctl separat betrachtet). Wenn ich z.B. rsyslog nutze, dann brauche ich 1 Tool zum Erstellen der Logs und (je nachdem wie man vorgeht) zwischen 1 und 20 Tools um die Dateien zu verarbeiten. Wenn man einigermaßen schnell zum Ziel kommen will braucht man mit grep, cut u.a. vermutlich eher so 5. Dazu kommt, dass das wirklich alles andere als intuitiv ist. Im Gegenteil, ich finde das ist sogar extrem umständlich. Wenn ich einfach nur wissen will, welche Logs es z.B. zu openntpd seit dem letzten Boot gab, dann mache ich folgendes:
journalctl -b 0 =openntpd
bzw. /usr/sbin/openntpd für die Bash-User: Dadurch erhalte ich genau das Gewünschte. Das oder ähnliches mit rsyslog + zig Tools zu erreichen ist relativ kompliziert. Für weniger geübte in grep & Co dauert es vermutlich sogar recht lange. Dazu kommt, dass die Konfiguration von syslog-ng und rsyslog ziemlich aufwendig ist, wenn man die Logdaten auf verschiedene Dateien sinnvoll aufgesplittet haben will. Ich hatte das vor ein paar Jahren mal bei syslog-ng gemacht und habe da glaube ich mehrere Stunden damit verbracht, bis es halbwegs übersichtlich war. Und selbst dann musste man viel greppen um an die gewünschten Infos heranzukommen. Mit journald ist das alles Vergangenheit. Sauber getrennt wird, indem ich einfach nach genau dem Frage was ich haben will und erhalte genau die Informationen, die ich angefragt habe und haben wollte. Dazu kann ich wie bisher im Übrigen auch grep und cut verwenden, denn die pure Ausgabe von journalctl ist ja quasi nix anderes als eine /var/log/messages, aber es ist zum einen total umständlich das zu machen und zum anderen vollkommen unnötig. In etwa so wie cat foo | grep bar.
Insofern könnte man eben sogar argumentieren, dass systemd zumindest in Teilen diese Unix-Philosophie sogar besser erfüllt als das z.B. bei rsyslog der Fall ist. Und wer (aus welchen Gründen auch immer) weiter auf die traditionellen Logservices setzen will, der kann das ja tun. journald ist keine Pflicht, man kann es sogar komplett abschalten (oder einfach nur im Memory lassen).
Wird nicht passieren, wenn man so hört, wie einige Gentoo Devs – die auch Einfluss beim Gentoo Council haben – Gift und Galle spucken, wenn jemand auch nur systemd erwähnt. Wahrscheinlich würde es nicht mal dann passieren, wenn 95% der Gentoo Nutzer nach der Gentoo-Installation erstmal systemd installieren (und so viele sind es wohl kaum).
Es ist nur noch eine Frage der Zeit bis systemd bei Gentoo zum Standard wird und nicht mehr "optional" ist
Soweit ich mich erinnere gibt es einen Council-Beschluß, daß openrc das primäre init-System von Gentoo ist (und auch bleibt) und alle anderen Implementierungen optional sind. Wobei meines Wissens nach neben openrc nur systemd wirklich einigermaßen gut gepflegt wird.
Gentoo läuft wunderbar mit systemd. Inzwischen schätzen auch immer mehr gentoo user die Vorzüge von systemd und experimentieren damit oder stellen ihr Init-System um.
Das ist wohl eher dem Zwang geschuldet, systemd zu verwenden, wenn man gnome-3.8 benutzen möchte.
"was nicht sein darf, das nicht sein kann" !!! Angeblich ist Gnome 3 doch so schlecht! Wieso sollte also jemand wegen Gnome3 sein Init-System umstellen?
Von Anonymous Coward am Fr, 3. Januar 2014 um 02:07 #
Upstart ist ein Alleingang. Um zu Upstart beizutragen muss man ein CLA unterschreiben und es wird auf Canonicals Infrastruktur gehostet. systemd dagegen wird auf freedesktop.org gehostet und es gibt kein Copyright Assignment. An wen auch? Denn anders als hier immer fälschlich behauptet wird, ist systemd kein Projekt von Red Hat, sondern ein Community-Projekt mit Beträgen von allen möglichen Firmen, Einzelentwicklern und Distributionen. Das ursprüngliche Design wurde maßgeblich von Kay Sievers mitgestaltet, der damals bei Novell arbeitete, wie jedermann in „Rethinking PID 1“ nachlesen kann.
Von Fester Shinetop am Do, 2. Januar 2014 um 17:25 #
Es wird von Canonical allein entwickelt. Es gibt keine Upstart-Entwickler, die nicht bei Canonical angestellt sind. Systemd hat eine offenere Entwicklercommunity, die Beitragende ermutigt, mit Beitragenden von diversen Firmen und Distributionen wie Samsung, Intel, Arch, Debian, Suse, Ubuntu mit Commit-Access ins Repository und keinerlei CLA-Forderungen.
" Es gibt keine Upstart-Entwickler, die nicht bei Canonical angestellt sind"
Das ist wohl eher nicht korrekt. Schau dir das Repo von Upstart an, da sind Commits von nicht-Canonical Mitarbeitern zu finden. U.a. von Red Hat. Die Oberfläche von launchpad ist aber leider nicht sehr Hilreich dabei, heraus zu finden wer wo arbeitet :/ Generell ist Launchpad bääh
Aber auch wenn es so wäre, ergäbe der Satz aus meiner Sicht so keinen Sinn / wäre noch immer nicht fair formuliert: "genutzten SysV Init das hauptsächlich bei Red Hat entwickelte Systemd, Canonicals Alleingang Upstart sowie das bei Gentoo entwickelte OpenRC"
Der Satz legt nahe, das auch die beiden Konkurrenten dieses Problem haben (ungeachtet dessen, ob das wahr ist), aber bei Canonical wird dies sehr negativ dargestellt. Bei den anderen lediglich ein Fakt. Abgesehen davon, bin ich mir recht sicher, dass die Formulierung auf die Nutzung / die Weigerung von Canonical zur Systemd Nutzung, abziehlt.
Die Oberfläche von launchpad ist aber leider nicht sehr Hilreich dabei, heraus zu finden wer wo arbeitet :/ Generell ist Launchpad bääh ;)
Das ist übrigens ein nicht zu verachtender Punkt. Upstart wird durch bzr (welches in der Community ja oft weniger als "bazaar" als eher "bizarre" ausgesprochen wird ;)) verwaltet, systemd durch git. Nun ist git unter den Entwicklern sehr verbreitet, es gibt zu anderen Versionsverwaltungstools (i.e. auch das sehr beliebte hg) gute Schnittstellen. Die gibt es bei bzr auch (u.a. z.B. git-bzr), sind aber längst nicht so etabliert und verbreitet. Das wirkt sich aber auch auf die Motivation von Entwicklern aus, beizutragen (wobei es per Patch natürlich immer geht).
Ist bei mir im Übrigen auch so. Projekte, die von bzr oder cvs (wo ich eh immer mit dem Kopf schütteln muss, dass es das noch gibt), lade ich mir als Repo generell nicht mehr runter, es sei denn ich finde spontan einen clone in git, svn oder hg. Rein mit tarballs zu arbeiten ist aber generell etwas mühsamer als wenn man das originale Repo hat.
> Upstart ist bei Debian in der Kritik, da es derzeit unter Linux lediglich von Canonical eingesetzt wird.
Nur weil es "lediglich von Canonical eingesetzt wird." ist schon eine schwache Argumentation.. aus Technischer Sicht, da sehe ich die Kritik gegen Systemd schon gravierender und bereitet mehr Probleme.
Anders gesagt zur Qualität einer Aussage & der Menge der Meinungen, vielleicht bisschen überspitzt ausgedrückt: Esst Scheiße – Millionen Fliegen können nicht irren
Nur weil es "lediglich von Canonical eingesetzt wird." ist schon eine schwache Argumentation..
Aus technischer Sicht gibt es durchaus auch Argumente gegen Upstart. Technische Schwächen wären aber nicht unbedingt das Problem, wenn man die Manpower hätte diese auszumerzen. Ob Canonical mit Debian zusammen das alleine kann weiß man nicht. Wer sonst noch dabei helfen würde, weiß man momentan wohl auch nicht so genau. Das sind schon offene Fragen, die sich eben auch stellen.
da sehe ich die Kritik gegen Systemd schon gravierender und bereitet mehr Probleme.
Bis heute habe ich nur wenige solche Kritik gelesen, die auch wirklich fundiert war und Bestand hatte/hat.
Esst Scheiße – Millionen Fliegen können nicht irren
Milliarden Menschen essen Brot. Daraus folgt aber nicht, dass Brot Scheiße ist, oder?
Naturgemäß fällt diese Entscheidung für Debian nicht leicht, denn beide Init-Systeme haben neben ihren Vorteilen auch jeweils zumindest einen gravierenden Nachteil. Systemd ist derzeit nur auf Linux-Systemen einsetzbar und somit für die Debian-Architekturen kFreeBSD und Hurd nicht verfügbar, da deren Kernel keine cgoups unterstützen.
Dieser Abschnitt ist so geschrieben als wäre das nur für systemd so, aber meines Wissens ist auch Upstart nicht auf die genannten Systeme portiert. Das ist auf Grund der POSIX-Kompatibilität nur bei OpenRC der Fall. Es mag schon sein, dass ein Port für Upstart prinzipiell möglich ist, aber ob Debian alleine den Aufwand dafür stemmen will? Außer Debian wären ja hauptsächlich Canonical an der Weiterentwicklung von Upstart interessiert und dass die großes Interesse an einem Port z.B. für Hurd, aber auch für BSD haben sollten kann man bezweifeln. Abgesehen davon meine ich gelesen zu haben, dass Hurd Mechanismen unterstützt die mit cgroups vergleichbar sind, da ich aber das System nicht wirklich kenne kann ich das nicht beurteilen. Im Endeffekt ist aber ein Mechanismus wie cgroups im System ohnehin mehr als wünschenswert, da nur so eine saubere Einteliung von Prozessen, deren Childs und Ressourcen möglich ist. Hier sollte BSD einfach nachlegen.
Canonical scheint allgemein bereit zu sein, upstart stehts so zu belassen, dass eine Portierung immer möglich bleibt. So ist cgroups Support fest eingeplant, aber durchgehend nur optional, obwohl jede Ubuntu-Plattform cgrousp unterstützt. Und das seit langem.
Der Wille ist also da. Ob man es auch für Debian gleich portiert... das glaub ich auch weniger.
Es scheint im Upstart-repo aktuell arbeiten an einem FreeBSD Port zu geben. Habe ich nur beim Überfliegen gesehen. Scheint doch etwas in diese Richtung zu passieren.
Man darf Debian/kFreeBSD und BSD nicht verwechseln. Free/Open/NetBSD wird ja von einer Handvoll Leute benutzt, Debian/kFreeBSD jedoch von niemandem, weder von BSD-Leuten (weil GNU-"verseucht"), noch GNU-Leuten, weil Debian/Linux für die einfach besser ist.
Wikipedia: cgroups (control groups) is a Linux kernel feature to limit, account and isolate resource usage (CPU, memory, disk I/O, etc.) of process groups. (fasst es nett zusammen )
Soweit ich es mal verstanden habe (es ist offen gesagt kein Thema, das mich bisher sonderlich interessiert hat), geht es für systemd aber wohl eher um die Kontrolle über die Prozesse. Sprich: Durch die cgroups bleiben Prozesse mit deren Forks und co. sauber gruppiert unter der Kontrolle des Systemdämons.
Was cgroups per Definiton sind hat LH_ ja bereits geschrieben. In der Realität werden sie vom Linux Kernel verwendet (soweit aktiviert), um Ressourcen zwischen Prozessen aufzuteilen. So könnte man der cgroup eines Benutzers Priorität einräumen oder die Ressourcen limitieren. systemd verwendet die cgroups für ähnliche Zwecke, aber etwas detailierter, da systemd als Init ja mehr Informationen darüber hat, welche Programme wie und wann gestartet wurden etc. So wird z.B. für jeden Service eine cgroup erstellt, z.B. cgroup-apache-service (das Namensschema ist vermutlich anders, aber das spielt hier ja keine Rolle). Wenn nun in Apache selbst Skripte ausgeführt werden, dann erhält jedes Skript eine neue PID. Bei sysvinit war es prinzipiell möglich, dass ein Skript durch geschicktes Forken so dem eigentlichen Service "entkommen" konnte. Wenn man also Apache abgeschalten hatte, waren unter Umständen noch Skripte aktiv, die hier ihren Ursprung hatten. Das ist aber nicht erwünscht. Wenn ein Service abgeschalten wird, dann sollten auch alle Child-Prozesse mit geschlossen werden. Genau das ermöglicht jetzt die cgroup-apache-service, denn alle Children fallen in diese cgroup. systemd kann dadurch den Apache Service und alle Prozesse in der cgroup schließen und so ein komplettes Abschalten des Prozesses ermöglichen. Zusätzlich ermöglicht es die Integration von logind in systemd, die Ressourcesaufteilung unter den Nutzern ebenfalls über cgroups zu regeln.
Das Begründungsstatement von Russ Albery fasst sehr fundiert die Vorteile von systemd zusammen. Man merkt, dass er sich die Mühe gemacht hat, die Systeme wirklich zu verwenden, zu evaluieren und zu vergleichen, und nicht allgemeines FUD zu verbreiten.
Wer verbreitet denn FUD ? Ich verfolge die DTC Mailinglist seit Tagen mit Argusaugen. Kann da nichts von FUD feststellen. Es kommen nur zahlreiche Kommentare von Leuten rein, die auch eine andere Sicht der Dinge haben. Und diese sollte man nicht ignorieren.
Ein weiterer Kritikpunkt ist, dass Systemd bei aller technischen Überlegenheit das alte Unix-Prinzip des »one tool for the job« völlig außer Acht läßt und außer dem Systemstart mit Journal und Logind weitere Systemverwaltungsaufgaben übernimmt.
Der Satz ist ja ein Widerspruch in sich :-) journald, logind, hostnamed, timedated, usw. sind eben exakt im alten Unix-Prinzip jeweils ein auf eine Funktionalität spezialisierte Services.
systemd ist leider hier ungünstigerweise sowohl der Name des Projekts als auch der Name eines der Dienste.
Gemeint ist hier eher, dass alle Tools in einem Paket kommen und so es etwas schwieriger wird, diese außerhalb der systemd-Umgebung zu nutzen (betrifft vor allem udev und logind). So groß ist das Problem allerdings auch nicht, seitens Debian will man ja offensichtlich manche systemd Tools wie udev, logind, hostnamed u.a. auch dann nutzen, wenn Upstart das neue Init System wird. Für eine Binärdistribution ist es auch überhaupt kein Problem diese Programme in separate Teile aufzuteilen. Bei Distributionen wie Gentoo wird das schon etwas schwieriger, aber ist auch machbar. Zumal die Kompilierzeit für systemd als ganzes auch auf langsameren Maschinen vertretbar ist (auf meinem 4 Kerner braucht es ca. 4min pro Architektur).
Das Paketieren ist der Job der Distribution. Nur wenn es ein einzelner großer Dienst wäre, stimmt die Aussage im Artikel. Es sind aber mehrere Dienste, die auch optional sind.
Ich fordere ein Abstimmung über Systemd, Upstart, Sysvinit und OpenRC unter den Debiananwendern. Manipulationen durch Firmen, die über Ihre Entwickler und deren an diese gebundenen Entscheidungen durchgedrückt werden könnten, wären so hundertprozentig vermeidbar.
Debian ist schließlich kein Entwicklerselbstzweck, die Anwender sollten entscheiden dürfen, welches Init-System in Zukunft in Debian standardmäßig verwendet wird.
Einfach einmal probieren. Vielleicht stimmen ja Millionen von Anwendern ab.
... dann müssen aber noch immer alle hinter den Auswahlmöglichkeiten stehenden Systeme gepflegt werden, inkl. aller daraus resultierenden Folgen (sowohl Entwicklungs- als auch Benutzungstechnisch) ...
...war eigentlich eher ironisch gemeint: wenn die User selbst entscheiden sollen, dann kann man gleich den Installer als Abstimmungswerkzeug nehmen. Beide Varianten, Abstimmung und Installer-Option, sind natürlich völliger Quatsch. Debian soll Upstart oder etwas anderes nehmen, nur nicht systemd, dessen Entwickler kFreeBSD, Hurd und sonstige Linux-Alternativen tot sehen wollen. Debian sollte diesen Vereinheitlichungsversuch nicht unterstützen. Und ich sage dies obwohl ich Canonical-Hasser bin...
Und du kannst deine Hand dafür ins Feuer legen, dass du (und viele andere) nicht durch Firmen manipuliert bist? Auch nicht ein bisschen?
Man könnte natürlich argumentieren, dass die Anwender ja evtl. Erfahrungen mit systemd/upstart/openrc haben, aber im Endeffekt sprechen wir hier von Debiananwendern und dort war weder das eine noch das andere bisher Standard. Natürlich gibt es Wechsler, aber ein großer Teil wird sich nie wirklich das eine oder das andere angeschaut haben.
Dadurch würde eine solche Abstimmung zu einem großen Teil zu einer "Glaubensfrage" mutieren und die Entscheidung für oder wider ein bestimmtes Init sollte keine Glaubensfrage sein (oder zumindest nicht wesentlich), sondern vor allem eine technische Frage (auch in Bezug auf den Aufwand der Debianmaintainer). Die "Millionen von Anwendern" werden aber genau davon keine Ahnung haben, wieso auch?
Da ich weiß, dass hier bei ProLinux gerne auf Canonical eingedroschen wird, frage ich mich allerdings, wieso anscheinend keiner "Bauchschmerzen" bekommt, wenn die "Freie Community" eine Ami-Firma wie RedHat mit ihrer zwangsläufigen Nähe zu NSA und Co. an wesentlichen Teilen des Linux-Systems herumwerkeln lässt?
Red Hat arbeitet auch am Linux Kernel mit, genauso wie viele andere amerikanische Firmen. SELINUX stammt sogar von der NSA selbst.
Durchaus möglich, dass so Lücken im Linux-Ökosystem eingebaut wurden, aber warum ausgerechnet in systemd, wenn man doch Zugriff auf den "Kern" selbst hat?
Bisher hat niemand in von Red Hat beigesteuertem Code entsprechende Hinweise gefunden.
Die Red Hat-Entwickler wären IMO die ersten, die solchen Crap zuerst veröffentlichen und an den Pranger stellen würden.
Wir reden hier von einer Firma, die z.B. als einzige einen Nouveau-Entwickler einstellte, um Nvidias Einfluss auf diese Treiber loszuwerden, um endlich einen wirklich freien Treiber zu haben. Mit Cups werden sie eines Tages genauso verfahren, wenn Apple diesbezüglich einmal "ausflippen" sollte.
Wenn in freier Software etwas eingebaut wurde, dann eher in Gestalt eines bestimmtem Algorithmus in einer Art "Software-Komposition". So etwas wie z.B. den Debian openSSL-Fehler kann man nicht dauerhaft oder sehr lange vor der Community verstecken.
Und dann bitte auch gleich openSUSE miterwähnen, das von SUSE kontrolliert wird und selbst wiederum zur US-Firma Attachmate gehört.
Slackware sollte man auch nicht vergessen, auch dieses ist rein US-basiert.
Und Ubuntu als britische (!) Distribution dürfte da in punkto Geheimdienstpenetration kaum besser als die US-Distributoren dran sein.
Und nun, Herr Paranoia, zeigen Sie mir bitte die entsprechenden Beispiele von betroffenem Code, egal wo, in RHEL/CentOS/SL/Fedora, in SLES/openSUSE, in Ubuntu (Server), in Slackware. Ich warte.
Nun Herr K_tz, selbst wenn ich Beispiele von betroffenem Code zeigen könnte, könnten Sie ihn denn verstehen? Und um wieviel Millionen Zeilen Code geht es denn bei SELinux und systemd?
Red Hat arbeitet eng mit der NSA zusammen, das wird wohl niemand bestreiten. Der Red Hat Vorstandsvorsitzende ist ein hoher Ex-Militär und die NSA unternimmt alles erdenkliche, um das Netz zu kontrollieren. Vielleicht ist ja noch keine "Backdoor" in Linux-System eingebaut, aber wie einfach lässt sich das nachholen? (https://lkml.org/lkml/2013/9/5/212) Und das war ein Red Hat-Entwickler, der versuchte den Code einzuschleusen...
Mir ist höchst unwohl dabei, wenn so was wichtiges wie das INIT-System aus diesen "dunklen Quellen" kommt. Firmen wie Apple, Google, Microsoft etc. konnten sich nicht dem Zugriff der NSA erwehren, warum sollte dann Red Hat, die die Zusammenarbeit ja direkt suchen, keine Hintertüren für die NSA einbauen?
Und bzgl. Nouveau denke ich, dass mit geringem Aufwand die Reputation in der Gemeinde enorm gesteigert wurde.
"Nun Herr K_tz, selbst wenn ich Beispiele von betroffenem Code zeigen könnte, könnten Sie ihn denn verstehen? Und um wieviel Millionen Zeilen Code geht es denn bei SELinux und systemd?"
Ich würde mich darum kümmern, das Leute diese Codeschnipsel zu sehen bekommen, die sich mit so etwas auskennen.
Es ist aber absolut unfair, irgendwelche Vermutungen in den Raum zu stellen, die durch nichts belegt sind. Das nennt sich eigentlich "Rufmord".
"Firmen wie Apple, Google, Microsoft etc. konnten sich nicht dem Zugriff der NSA erwehren,"
Solange man mit Closed Source-Code arbeitet, mag das so sein. Auch der NSA ist aber klar, dass der Sourcecode freier Software veröffentlicht werden wird. Das muss nicht heißen, dass in freier Software keine Backdoors enthalten sein können, nur müssen diese viel aufwendiger implementiert werden. Nichtsdestotrotz wird man, falls z.B Selinux eine solche Backdoor enthalten sollte, diese eines Tages an Ihrer bloßen Funktionsfähigleit erkennen. Linux protokolliert ja im allgemeinen sehr gut, was das eigene System so anstellt.
Trotzdem genügt auch hier nicht der bloße Verdacht. Irgendetwas Handfestes, das einen Verdacht begründet, muss schon vorhanden sein, Auffälligkeiten im Code, Bugs in der Funktionsfähigkeit, kompliziert zu behebende Sicherheitslücken.
Falls Dein bisher haltloser Verdacht gegenüber Linuxfirmen tatsächlich wahr wäre, so wäre jedes Linux "verseucht". Auch der Kernel-Chef ist ja mittlerweile US-Staatsbürger. Wenn Red Hat "fällt", fallen unter Umständen auch die "Anderen".
Und bitte nicht vergessen: Auch Festplatten- und Routerhersteller sowie Netzwerkausrüster und Computer-Hardwarehersteller scheinen in dem NSA-Geflecht zumindest Opfer gewesen zu sein. Das heißt, dass Dein Computer, insofern er nach etwa 1995 gebaut wurde, schon alles hardware- und firmwaremäßig enthalten könnte, was man bräuchte, um auf das zuzugreifen, was man von Dir, mir und Millionen anderer Computernutzer gerne lesen möchte. Da hilft im Prinzip dann nur noch die Abkopplung des eigenen Rechners von öffentlichen, unsicheren Netzwerken wie dem Internet. Fürden Fall, dass Du Dich dazu entschließen solltest, sage ich schon einmal "Auf Wiedersehen".
Denn warum sollten Organisationen wie die NSA mit Ihren Aktionen erst bei der Software ansetzen? Ich würde auf der Stufe darunter aktiv werden, eben auf der Stufe der Hard- und Firmware (Mainboard-Bios, Steckkarten-Bios und - RAM, Festplattenfirmware, usw.). Dies wäre ungeheuer effektiv. Eine so mächtiges Land wie die USA könnte dies tatsächlich hinbekommen (haben). Das hätte auch den netten Vorteil, dass die meisten Betroffenen niemals merken würden, dass sie ausgehorcht wurden.
Aber wie schon gesagt: Ein Hätte, Wäre, Könnte genügt nicht zur Anklage.
"...Ein Hätte, Wäre, Könnte genügt nicht zur Anklage..."
Es geht nicht um eine Anklage, sondern darum, welches INIT-System die wohl wichtigste "unabhängige, freie Community" wählen wird.
"Denn warum sollten Organisationen wie die NSA mit Ihren Aktionen erst bei der Software ansetzen?"
Tun sie ja nicht, sie setzen auf allen möglichen Ebenen an, Software, Hardware, Firmware, Unterseekabel, Wanzen, Drohnen etc. Und hier weiter gedacht: Warum sollten sie unser Linux-System aussparen, wenn es da schon die Möglichkeiten der direkten Mitarbeit und Einflussnahme gab/gibt?
"Falls Dein bisher haltloser Verdacht gegenüber Linuxfirmen tatsächlich wahr wäre, so wäre jedes Linux "verseucht"."
Es geht nicht um einen Verdacht gegenüber "Linux-Firmen", sondern darum, wie andere Leser hier diese Nähe von Red Hat zur NSA sehen und bewerten, angesichts der Tatsache, dass die Wahl des INIT-Systems durch Debian von durchaus weitreichender Bedeutung sein wird. Hier wird immer gerne auf Canonical eingedroschen, aber niemand scheint sich Gedanken um eine Firma wie Red Hat zu machen, das finde ich einseitig.
Aber vielleicht mache ich mir unnötige Sorgen und Systemd, in Kombination mit SELinux ist für die Experten hier und dich völlig transparent, weil ihr den Source-Code dazu vollkommen versteht und schon durchgelesen habt?
"Aber vielleicht mache ich mir unnötige Sorgen und Systemd, in Kombination mit SELinux ist für die Experten hier und dich völlig transparent, weil ihr den Source-Code dazu vollkommen versteht und schon durchgelesen habt?"
Nein, natürlich nicht.
Ich habe ebenfalls Vorbehalte gegenüber Systemd. IMO ist es nicht wesentlich schneller als Sysvinit (unter openSUSE wird die "Schnelligkeit" von Systemd u.a. dadurch gesteigert, dass der X-Server noch vor dem Herstellen der Netzwerkverbindung hochfährt; bei einem Vergleich von Sysvinit-openSUSE 11.4 mit Systemd-openSUSE 13.1) und die zwei, drei Dinge, die Systemd besser macht, könnte man auch versuchen, in Sysvinit zu integrieren.
Zudem mag ich den momentanen Gnome3-Standard in Debian nicht besonders, und wenn das systemd-abhängige Gnome3 dadurch gegenüber einer GUI wie Xfce unter Debian endgültig ins Hintertreffen gerät, so wäre mir dies sehr recht.
Ich kann mich alledings auch nicht für Upstart erwärmen, es ist im Vergleich zu Sysvinit IMO kein wirklicher Fortschritt.
Fazit: Meine Antwort zu Systemd und Upstart: Nein.
Kubuntu und Linux Mint setzen systemd in ihren aktuellen Distris ein. Beide sind Ubuntu-Paket-kompatibel. Bei Ubuntu ist systemd seit April 2013 in den Repos. Siehe auch hier: https://en.wikipedia.org/wiki/Systemd#Adoption
Ich habe LM16 MATE jetzt auf zwei Maschinen installiert. Läuft prima.
Ich finde an keiner Stelle einen Hinweis, dass das aktuelle Kubuntu auf systemd setzt. Gibt es da eine Quelle? Nur weil es seit April/2013 in den Repos ist bedeutet das nicht, dass es auch benutzt wird. Steht auch so im Wiki: Enabled by default -> no
Ich habe meine Maschinen auf Kubuntu 13.10 aktualisiert und seitdem laufen systemd-udevd und systemd-logind. Ohne mein Zutun, bereitgestellt durch das Paket "systemd-services".
Nach dem ich Kubuntu 14.04 in einer VM installiert habe, kam ich zu noch einem anderen Ergebnis. Das nutzt systemd-logind und systemd-shim (this package emulates the systemd function that are required to run the systemd helpers without using the init service). Was immer das bedeutet. Allerdings und das hatte ich auch erwartet, nutzt es Upstart.
"Canonicals Alleingang Upstart"
Wie meinen?
Upstart wurde und wird in anderen Distries benutzt. U.a. auch eine zeit lang von Red Hat.
So what?
> U.a. auch eine zeit lang von Red Hat.
naja, "benutzt" wurde es eigentlich recht wenig. RHEL6 startet nur das mit upstart, was frueher in /etc/inttab stand (getty u.ae). Services wurden nie ueber upstart gestartet.
IMO lag das an der Fehlkonzeption von Upstart, dass es keinen Mechanismus gab (gibt?), Dienste zu aktivieren bzw. deaktivieren (ala "systemctl enable/disable service").
In upstart musste (muss?) das durch Manipulation einer komplexen "start on" Zeile geschehen, was nicht der RH Weg ist.
Die Fehlkonzeption von Upstart (und übrigens auch von OpenRC) war eigentlich eher, dass man so nahe wie möglich am alten System bleiben wollte. Das was du schreibst ist ja im Endeffekt auch eine Folge genau davon.
Dazu kommt, dass man das Problem der Abhängigkeiten zwischen Services (die eben zweifelsohne existieren) eigentlich ignorieren wollte (und auch eine gewisse Zeit ignoriert hat), wobei es meines Wissens inzwischen gelöst ist.
Ein Auto wird eben auch nie wirklich gut fliegen können, nur weil ich 2 Flügel dran schraube. Wenn man es gut macht kann es funktionieren, aber manchmal ist es eben auch sinnvoller das gesamte Konzept zu überdenken. Genau das hat dann letztendlich erst systemd gemacht.
In manchen Teilen ist systemd evtl. über das Ziel hinaus geschossen, aber das ist dann wieder eine andere Diskussion.
"Die Fehlkonzeption von Upstart (und übrigens auch von OpenRC) war eigentlich eher, dass man so nahe wie möglich am alten System bleiben wollte."
Ohne Zweifel ein Problem, aber ein nachvollziehbares. Immerhin hatte es vorher kein radikales neues System geschaff sich durchzusetzen.
Vor systemd hätte doch niemand ernsthaft geglaubt, das ein Wechsel möglich wäre. Auch jetzt geht es nur, weil Red Hat voll dahinter steht. Würde Red Hat "no" sagen, hätten alle ein Problem.
Für viele ist Red Hat eben das maß aller Dinge für solche Entscheidungen.
Hier ist Canonical etwas der geschundene: Sie durften ausloten wie Weit die Akzeptanz geht für einen Init-Ersatz. Als klar war das alle bereit sind, hat Red Hat etwas eigenes gebaut.
Erst durch Upstart wurde aber klar, wie weit man die Neuentwicklung treiben konnte.
Sicherlich hat Canonical auch etwas zu zaghaft reagiert, aber Lennart Poettering war nun - so mein Eindruck - auch nicht gerade dabei, dort hin eine Hand zu reichen.
Das soll Upstart auch gar nicht abwerten, man muss ja Canonical zu Gute halten, dass sie zumindest versucht haben, Init zeitgemäßer zu gestalten. Man hätte aber durchaus auch damit rechnen müssen, dass so etwas passiert, wenn man eben nur den halben Weg geht.
Man könnte sogar noch weiter gehen und behaupten, dass systemd ohne Upstart nicht so weit wäre wie es heute ist. Bestes Beispiel ist hier doch HAL. Das Konzept war sicher interessant, aber schon recht bald war klar, dass dieser radikale Ansatz auch wieder abgelöst werden würde.Im Grunde war Upstart also der Versuch für die Tonne (sorry @ Canonical, aber in meinen Augen ist es so), den es aber ein Stück weit auch einfach gebraucht hat.
Wieso sollte Lennart Canonical die Hand reichen?
1) Schreib er ja schon in seinem Blog das Upstart zwar nett "geschrieben" ist aber das Konzept "mehhh"
2) Canonical hat sowieso immer auf die Community und den Upstream geschi*en, denen würde ich auch nicht die Hand reichen
> Würde Red Hat "no" sagen, hätten alle ein
> Problem. Für viele ist Red Hat eben das maß
> aller Dinge für solche Entscheidungen.
Würde Debian zu systemd "no" sagen, hätten auch viele ein Problem. Es tun ja schon massenweise Idividuen aufmüpfen, weil sie systemd einfach nur hassen.
Wieso machen wir eigentlich keinen Fork von Systemd fuer alle unixes? Achso ihr habt auch keine Zeit dafuer....wie gross waehre denn der arbeitsaufwand?
Es hat niemand um die Entwicklung von systemd gebeten. Also muss man auch keine Zeit habem es zu forken.
Kennst du diesen Spruch "Hallo, ich bin der Neue" und dann gabs mächtig beef, weil der Neue alles anders machen wollte ?
In der Situation stecken wir gerade.
Tun WIR das??? Was willst du damit sagen? Es hat ja auch niemand um Linux gebeten, wenn du keine bessere loesung hast wird halt die scheinbar beste genommen, mit deiner einstellung wird es genau so sein wie andere es wollen...aber sicher nicht genau so wie du es willst...das wirst vom mitmachen nicht verschont.
PS: Ich fand die entwicklung des Rad schon scheisse, das gibt nur stress und zeitdruck und die uebrigen sklaven pluecken nun orangen in suedspanien, eine Pyramide ist da schon sinvoller.
> Kennst du diesen Spruch "Hallo, ich bin der Neue" und dann gabs mächtig beef
Genau so kommt mir die Linux Community aktuell vor. Es wird wahllos auf alles neue eingedroschen, egal worum es geht und ohne vorher zu schauen ob das Neue vielleicht Vorteile bringt oder alte Probleme löst. Nö, alles Neue ist erstmal Mist - nachher muss man noch alte Gewohnheiten ablegen oder liebgewonnene Workarounds beseitigen.
Es geht nicht immer um das "Technologische" sondern auch um das "Politische". Das technologisch Beste kann u.U. eine politische Katastrophe bedeuten. Die noch nicht absehbaren Folgeerscheinungen sind außen vor. Daher sollte man mit Bedacht vorgehen und ggf. einen Mittelweg mit alternativer Technologie fahren. Debian macht das ganz richtig. Man denkt vorher etliche - nicht alle - Szenarien durch und entscheidet dann anhand der gesammelten Erkennntisse. Dies hätte ich mir von anderen Distributionen auch gewünscht, bevor sie "blind" auf "systemd" aufsprangen.
Es geht mir vor allem um die Formulierung im Text, nicht so sehr wie weit Red Hat wirklich upstart genutzt hat, oder ob man upstart für passend hält.
Der Text hat einfach an der genannten Stelle unnötig eine Wertung eingebracht, die gleichwohl für die Konkurrenten nicht gebraucht wurde, obwohl sie alle das gleiche Vorgehen haben.
Sicherlich ist es nicht nur mein Eindruck, das nur deswegen von "Alleingang" gesprochen wird, weil es Canonical ist. Wäre Red Hat gerade an dieser Stelle, wäre keine solche Formulierung benutzt worden. Ich kann mich auch an keinen solchen Fall erinnern, als systemd neu war, und upstart schon Verbreitung gefunden hatte (in den News, nicht in den Kommentaren).
Zumal das weiter Nutzen einer Lösung, die auch andere gebrauchten, als "Alleingang" nicht wirklich fair bezeichnet ist. Zumal upstart, als es zuerst eingesetzt wurde, eine von vielen Seiten willkommene Entwicklung war.
Nur weil Canonical nicht auf den ersten nächsten Zug aufspringt, sie dafür zu schelten, muss das sein?
Es kann mir keiner erzählen, das eine solche Formulierung ein versehen ist. Zumal es bei Gentoo dann nett als "Gentoo entwickelte OpenRC" formuliert ist.
Wir haben also im Satz 2x entwicklungen, und einen Alleingang. Bravo...
1. Canonical entwickelt im Alleingang Upstart
2. Andere (u.a. Novell und Red Hat) springen auf den Zug auf
3. Red Hat entwickelt im Alleingang systemd
4. Viele wechseln auf systemd
5. Unter den Distributionen, die neu veröffentlicht werden setzt eigentlich nur noch Ubuntu auf Upstart, insofern kann man in Zukunft durchaus wieder von einem Alleingang sprechenMuss man selbstverständlich nicht. Ich glaube es haben auch nicht wirklich viele damit ein Problem, dass Upstart weiter in Ubuntu verwendet werden soll. Problematisch wird es ja erst dann, wenn man seitens Canonical versucht Einfluss auf andere Distributionen (hier Debian) zu nehmen. Dann gibt es natürlich Knatsch, auch wenn man das seitens Canonical verstehen kann. Natürlich versuchen sie ihre Lösung in Debian unterzubringen, welches ja im Endeffekt die Basis für Ubuntu stellt.
Was die anderen Distributionen angeht kann man aber schon verstehen, dass sich immer mehr in Richtung systemd bewegen, denn neben den technischen Vorteilen muss man auch neidlos anerkennen, dass systemd mehr zur Vereinheitlichung der Linux-Platform beigetragen hat als die LSB das jemals vermocht hat. Was gab es früher einen Wildwuchs an Konfigurationsdateien, Verzeichnisstrukturen etc... Hier hat systemd endlich mal zum Teil Abhilfe geschaffen. Nicht immer zur Zufriedenheit alle (siehe Diskussion um /usr), aber eben doch effektiv.
Seitens Canonical kann man sich aber zumindest damit trösten, dass der "Zug" zumindest nie abgefahren sein, denn ein Wechsel auf systemd ist im Endeffekt fast von heute auf morgen möglich.
Was meines Wissens noch nicht mal ganz richtig ist. OpenRC wird inzwischen von Gentoo weiterentwickelt, aber seine Ursprünge hat es so weit mir bekannt außerhalb von Gentoo. Ich meine mich sogar zu erinnern, dass das Ziel damals eher die BSD Platform war, aber auf Grund der Konzeption (braucht nur eine POSIX Shell) dann natürlich auch auf Linux lief. Da der Entwickler ursprünglich bei Gentoo war war es auch in vielen Punkten eng an Gentoos damaliger Ausführung von Init angelehnt, so dass eine Migration sich anbot. Dazu kommt dann natürlich, dass Gentoo (wie viele andere Distributionen) unter dem NIH-Syndrom leidet (was man auch verstehen kann, wenn viel Zeit in einen gewissen Teil der Distribution investiert wurde), ist es schon verständlich, dass man daran festhält, auch wenn es sicher unter Gentoo recht einfach ist, OpenRC durch systemd zu ersetzen. (Vermutlich auch deutlich einfacher als unter Ubuntu Upstart zu ersetzen.)Muss gleich los, daher nur eine fixe Antwort
"Das stimmt, aber wenn man es genau betrachtet ist es doch so:
1. Canonical entwickelt im Alleingang Upstart
2. Andere (u.a. Novell und Red Hat) springen auf den Zug auf
3. Red Hat entwickelt im Alleingang systemd
4. Viele wechseln auf systemd"
Bis hierhin stimme ich zu.
"5. Unter den Distributionen, die neu veröffentlicht werden setzt eigentlich nur noch Ubuntu auf Upstart, insofern kann man in Zukunft durchaus wieder von einem Alleingang sprechen"
Hier aber nicht :)
Mein Problem ist, das die Linuxwelt sich noch nicht geschlossen für eine Richtung entschieden hat. Upstart hat - absolut ohne Zweifel - viel an Boden verloren. Aber noch immer ist es eine normale und auch außerhalb genutzte Lösung, die Canonical natürlich nicht einfach fallen lässt. Es gibt noch immer Distries (vor allem Debian), wie sich nicht entschieden haben.
In einem solchen Umfeld halte ich die Bezeichnung für nicht passen, ja unfair.
Nun müsste eine Seite wie PL nicht unbedingt fair sein, eigene Meinungen sind erlaubt, auch bei News. Aber normalerweise ist PL relativ neutral, und dann sollte es dies durchgehend sein, das wäre angemessen.
Wenn einmal 99% der anderen Distries systemd nutzen (falls es so kommt), und Canonical würde Stur und mit vielen Nachteilen weiter upstart nutzen, dann wäre es sicher ein Alleingang. Aber aktuell ist Systemd optional, bringt noch kaum echte Vorteile, andere Distries sind unentschlossen oder nutzen auch mal upstart (auch mobil gibts ein paar Geräte, die das tun) usw.
Es ist einfach nicht der Moment, um von einem Alleingang zu reden. Wir sind an der Schwelle zur Entscheidung.
a) Alle nutzen systemd
b) Systemd und upstart werden parallel genutzt.
ein "c) nur upstart" ist unwahrscheinlich, das ist mit Red Hat nicht zu machen. Sonst hätten wir alle heute auch das Debian Format im Einsatz ;D
Googles Chrome OS verwendet wohl momentan auch Upstart. Wie das in der Zukunft sein wird weiß aber natürlich nur Google.
Das mag alles stimmen. Nur, was machen wir damit:
Unter dem Gesichtspunkt halte ich eine Diskussion über die "Alleingänge" von Ubuntu oder Red Hat für unsinnig.
Bei ersterem Problem muß Debian ein Problem lösen, dass viele andere Distributionen gar nicht haben.
Und diese Probleme einfach wegzudiskutieren scheint ja wohl kaum möglich zu sein.
Ich sehe das daher so:
Debian sollte für Linux systemd verwenden (oder upstart, wenn sie denn unbedingt wollen) und für die beiden anderen Architekturen OpenRC. Systemspezifische Lösungen wird es ohnehin immer geben, man wird nie alle 3 komplett unter einen Hut bringen können.
Upstart oder systemd zu portieren halte ich nur dann (und auch wirklich nur dann) für sinnvoll, wenn andere BSD Distributoren (i.e. FreeBSD oder NetBSD) ein ernsthaftes Interesse daran haben und mithelfen.
Was den zweiten Teil angeht:
Das stimmt so einfach nicht. Natürlich bringt systemd eine Reihe Tools in einem Paket mit, aber das macht z.B. coreutils auch. Oder kde-workspace. Da hat sich auch niemand beschwert, zumindest nicht mit diesem Argument. (Bei KDE kommt immer mal wieder die Frage nach den Abhängigkeiten und dem Umfang auf, aber das Zusammenfassen selbst wird nicht in Frage gestellt.)Genauer gesagt gibt es hier 2 Aspekte:
bzw. /usr/sbin/openntpd für die Bash-User:1. Distributive Seite:
Nicht wirklich ein Problem. Wie ich bereits erwähnte ist die Kompilierzeit für das komplette systemd Paket inkl. logind, journald, udev etc. gering. Ob 3 oder 4 Minuten spielt wirklich keine Rolle. Für Binärdistributionen kann man das Ergebnis einfach in verschiedene Teile aufspalten. Das wird bei Debian ja ohnehin auch so geplant. Z.B. logind und udev soll in jedem Fall verwendet werden, auch wenn Upstart das init wird. Für Sourcedistributionen ist es etwas schwieriger, aber angesichts der kurzen Kompilierzeit auch nicht schlimm. Ok, es nimmt ein bisschen Platz auf der HDD weg, wenn man noch Binaries rumliegen hat, die man nicht braucht, aber wenn es nach dem Gesichtspunkt geht, dann gibt es sicher hunderte anderer Beispiele, die wesentlich gravierender sind.
2. Technische Seite:
Ich hab mir den Sourcecode jetzt nicht im Detail angeschaut, aber soweit ich das sehen kann, sind die Tools sauber getrennt. Wenn man es genauer betrachtet, erfüllt journald z.B. sogar wesentlich präziser die genannten Anforderungen, nämlich 1(!) Tool für Loggingzwecke (bzw. 2, wenn man journald und journalctl separat betrachtet). Wenn ich z.B. rsyslog nutze, dann brauche ich 1 Tool zum Erstellen der Logs und (je nachdem wie man vorgeht) zwischen 1 und 20 Tools um die Dateien zu verarbeiten. Wenn man einigermaßen schnell zum Ziel kommen will braucht man mit grep, cut u.a. vermutlich eher so 5. Dazu kommt, dass das wirklich alles andere als intuitiv ist. Im Gegenteil, ich finde das ist sogar extrem umständlich. Wenn ich einfach nur wissen will, welche Logs es z.B. zu openntpd seit dem letzten Boot gab, dann mache ich folgendes:
Dadurch erhalte ich genau das Gewünschte. Das oder ähnliches mit rsyslog + zig Tools zu erreichen ist relativ kompliziert. Für weniger geübte in grep & Co dauert es vermutlich sogar recht lange. Dazu kommt, dass die Konfiguration von syslog-ng und rsyslog ziemlich aufwendig ist, wenn man die Logdaten auf verschiedene Dateien sinnvoll aufgesplittet haben will. Ich hatte das vor ein paar Jahren mal bei syslog-ng gemacht und habe da glaube ich mehrere Stunden damit verbracht, bis es halbwegs übersichtlich war. Und selbst dann musste man viel greppen um an die gewünschten Infos heranzukommen. Mit journald ist das alles Vergangenheit. Sauber getrennt wird, indem ich einfach nach genau dem Frage was ich haben will und erhalte genau die Informationen, die ich angefragt habe und haben wollte. Dazu kann ich wie bisher im Übrigen auch grep und cut verwenden, denn die pure Ausgabe von journalctl ist ja quasi nix anderes als eine /var/log/messages, aber es ist zum einen total umständlich das zu machen und zum anderen vollkommen unnötig. In etwa so wie cat foo | grep bar.
Insofern könnte man eben sogar argumentieren, dass systemd zumindest in Teilen diese Unix-Philosophie sogar besser erfüllt als das z.B. bei rsyslog der Fall ist. Und wer (aus welchen Gründen auch immer) weiter auf die traditionellen Logservices setzen will, der kann das ja tun. journald ist keine Pflicht, man kann es sogar komplett abschalten (oder einfach nur im Memory lassen).
Na und?
Es ist nur noch eine Frage der Zeit bis systemd bei Gentoo zum Standard wird und nicht mehr "optional" ist
Debatten gab es ja schon darüber
Wird nicht passieren, wenn man so hört, wie einige Gentoo Devs – die auch Einfluss beim Gentoo Council haben – Gift und Galle spucken, wenn jemand auch nur systemd erwähnt. Wahrscheinlich würde es nicht mal dann passieren, wenn 95% der Gentoo Nutzer nach der Gentoo-Installation erstmal systemd installieren (und so viele sind es wohl kaum).
Kann sich noch jemand an das eudev-Kasperltheater erinnern? Scheint auch wieder eingeschlafen zu sein.
Seit 2 Monaten keine Commits mehr: github.com/gentoo/eudev
Die Bugs die zu den Fork geführt haben sind aber auch nicht gefixt und die sind doch schon seit mehr als einen Jahr bekannt.
Und welche Bugs sollen das sein?
Gentoo läuft wunderbar mit systemd. Inzwischen schätzen auch immer mehr gentoo user die Vorzüge von systemd und experimentieren damit oder stellen ihr Init-System um.
"was nicht sein darf, das nicht sein kann" !!! Angeblich ist Gnome 3 doch so schlecht! Wieso sollte also jemand wegen Gnome3 sein Init-System umstellen?
Upstart ist ein Alleingang. Um zu Upstart beizutragen muss man ein CLA unterschreiben und es wird auf Canonicals Infrastruktur gehostet. systemd dagegen wird auf freedesktop.org gehostet und es gibt kein Copyright Assignment. An wen auch? Denn anders als hier immer fälschlich behauptet wird, ist systemd kein Projekt von Red Hat, sondern ein Community-Projekt mit Beträgen von allen möglichen Firmen, Einzelentwicklern und Distributionen. Das ursprüngliche Design wurde maßgeblich von Kay Sievers mitgestaltet, der damals bei Novell arbeitete, wie jedermann in „Rethinking PID 1“ nachlesen kann.
Es wird von Canonical allein entwickelt. Es gibt keine Upstart-Entwickler, die nicht bei Canonical angestellt sind. Systemd hat eine offenere Entwicklercommunity, die Beitragende ermutigt, mit Beitragenden von diversen Firmen und Distributionen wie Samsung, Intel, Arch, Debian, Suse, Ubuntu mit Commit-Access ins Repository und keinerlei CLA-Forderungen.
" Es gibt keine Upstart-Entwickler, die nicht bei Canonical angestellt sind"
Das ist wohl eher nicht korrekt.
Schau dir das Repo von Upstart an, da sind Commits von nicht-Canonical Mitarbeitern zu finden. U.a. von Red Hat.
Die Oberfläche von launchpad ist aber leider nicht sehr Hilreich dabei, heraus zu finden wer wo arbeitet :/
Generell ist Launchpad bääh
Aber auch wenn es so wäre, ergäbe der Satz aus meiner Sicht so keinen Sinn / wäre noch immer nicht fair formuliert: "genutzten SysV Init das hauptsächlich bei Red Hat entwickelte Systemd, Canonicals Alleingang Upstart sowie das bei Gentoo entwickelte OpenRC"
Der Satz legt nahe, das auch die beiden Konkurrenten dieses Problem haben (ungeachtet dessen, ob das wahr ist), aber bei Canonical wird dies sehr negativ dargestellt. Bei den anderen lediglich ein Fakt.
Abgesehen davon, bin ich mir recht sicher, dass die Formulierung auf die Nutzung / die Weigerung von Canonical zur Systemd Nutzung, abziehlt.
Nun ist git unter den Entwicklern sehr verbreitet, es gibt zu anderen Versionsverwaltungstools (i.e. auch das sehr beliebte hg) gute Schnittstellen. Die gibt es bei bzr auch (u.a. z.B. git-bzr), sind aber längst nicht so etabliert und verbreitet.
Das wirkt sich aber auch auf die Motivation von Entwicklern aus, beizutragen (wobei es per Patch natürlich immer geht).
Ist bei mir im Übrigen auch so. Projekte, die von bzr oder cvs (wo ich eh immer mit dem Kopf schütteln muss, dass es das noch gibt), lade ich mir als Repo generell nicht mehr runter, es sei denn ich finde spontan einen clone in git, svn oder hg. Rein mit tarballs zu arbeiten ist aber generell etwas mühsamer als wenn man das originale Repo hat.
Eric S. Raymond hat gerade heute dazu aufgerufen für Emacs von Bazaar auf Git umzusteigen, weil Bazaar am sterben ist.
> Schau dir das Repo von Upstart an,
Das mach ich doch.
> da sind Commits von nicht-Canonical Mitarbeitern zu finden.
Dann kannst du mir sicher auch welche zeigen zeigen, muss wohl schon lange her sein.
Upstart-Repo
Ich sehe immer nur die Canonical-Mitarbeiter James Hunt, Steve Langasek, Dimitri Ledkov, Stéphane Graber, Ted Gould, und früher Scott James Remnant.
> Upstart ist bei Debian in der Kritik, da es derzeit unter Linux lediglich von Canonical eingesetzt wird.
Nur weil es "lediglich von Canonical eingesetzt wird." ist schon eine schwache Argumentation.. aus Technischer Sicht, da sehe ich die Kritik gegen Systemd schon gravierender und bereitet mehr Probleme.
Anders gesagt zur Qualität einer Aussage & der Menge der Meinungen, vielleicht bisschen überspitzt ausgedrückt:
Esst Scheiße – Millionen Fliegen können nicht irren
>Daraus folgt aber nicht, dass Brot Scheiße ist, oder?
Aber auch nicht das es gut ist...
Nö, aber das hat auch niemand behauptet, oder?
ich glaub auch nicht
*g*
Es mag schon sein, dass ein Port für Upstart prinzipiell möglich ist, aber ob Debian alleine den Aufwand dafür stemmen will?
Außer Debian wären ja hauptsächlich Canonical an der Weiterentwicklung von Upstart interessiert und dass die großes Interesse an einem Port z.B. für Hurd, aber auch für BSD haben sollten kann man bezweifeln.
Abgesehen davon meine ich gelesen zu haben, dass Hurd Mechanismen unterstützt die mit cgroups vergleichbar sind, da ich aber das System nicht wirklich kenne kann ich das nicht beurteilen.
Im Endeffekt ist aber ein Mechanismus wie cgroups im System ohnehin mehr als wünschenswert, da nur so eine saubere Einteliung von Prozessen, deren Childs und Ressourcen möglich ist. Hier sollte BSD einfach nachlegen.
Canonical scheint allgemein bereit zu sein, upstart stehts so zu belassen, dass eine Portierung immer möglich bleibt.
So ist cgroups Support fest eingeplant, aber durchgehend nur optional, obwohl jede Ubuntu-Plattform cgrousp unterstützt. Und das seit langem.
Der Wille ist also da. Ob man es auch für Debian gleich portiert... das glaub ich auch weniger.
Es scheint im Upstart-repo aktuell arbeiten an einem FreeBSD Port zu geben. Habe ich nur beim Überfliegen gesehen. Scheint doch etwas in diese Richtung zu passieren.
BSD? Für die BSD Jungs ist die GPL ja schon Teufelswerk, die werden sich ganz sicher über die CLA freuen.
Man darf Debian/kFreeBSD und BSD nicht verwechseln. Free/Open/NetBSD wird ja von einer Handvoll Leute benutzt, Debian/kFreeBSD jedoch von niemandem, weder von BSD-Leuten (weil GNU-"verseucht"), noch GNU-Leuten, weil Debian/Linux für die einfach besser ist.
...hieße doch letztlich nicht nur eine Entscheidung gegen systemd, sondern letztlich auch gegen Gnome. Oder sehe ich das falsch?
Wie aufwändig wäre es, die BSD- und Hurd-Kernel mit cgroups-Unterstützung auszustatten? Was sind diese cgroups eigentlich?
Grüße!
Wikipedia:
)
cgroups (control groups) is a Linux kernel feature to limit, account and isolate resource usage (CPU, memory, disk I/O, etc.) of process groups.
(fasst es nett zusammen
Soweit ich es mal verstanden habe (es ist offen gesagt kein Thema, das mich bisher sonderlich interessiert hat), geht es für systemd aber wohl eher um die Kontrolle über die Prozesse. Sprich: Durch die cgroups bleiben Prozesse mit deren Forks und co. sauber gruppiert unter der Kontrolle des Systemdämons.
Was cgroups per Definiton sind hat LH_ ja bereits geschrieben. In der Realität werden sie vom Linux Kernel verwendet (soweit aktiviert), um Ressourcen zwischen Prozessen aufzuteilen. So könnte man der cgroup eines Benutzers Priorität einräumen oder die Ressourcen limitieren.
systemd verwendet die cgroups für ähnliche Zwecke, aber etwas detailierter, da systemd als Init ja mehr Informationen darüber hat, welche Programme wie und wann gestartet wurden etc. So wird z.B. für jeden Service eine cgroup erstellt, z.B. cgroup-apache-service (das Namensschema ist vermutlich anders, aber das spielt hier ja keine Rolle). Wenn nun in Apache selbst Skripte ausgeführt werden, dann erhält jedes Skript eine neue PID. Bei sysvinit war es prinzipiell möglich, dass ein Skript durch geschicktes Forken so dem eigentlichen Service "entkommen" konnte. Wenn man also Apache abgeschalten hatte, waren unter Umständen noch Skripte aktiv, die hier ihren Ursprung hatten. Das ist aber nicht erwünscht. Wenn ein Service abgeschalten wird, dann sollten auch alle Child-Prozesse mit geschlossen werden. Genau das ermöglicht jetzt die cgroup-apache-service, denn alle Children fallen in diese cgroup. systemd kann dadurch den Apache Service und alle Prozesse in der cgroup schließen und so ein komplettes Abschalten des Prozesses ermöglichen.
Zusätzlich ermöglicht es die Integration von logind in systemd, die Ressourcesaufteilung unter den Nutzern ebenfalls über cgroups zu regeln.
Das Begründungsstatement von Russ Albery fasst sehr fundiert die Vorteile von systemd zusammen. Man merkt, dass er sich die Mühe gemacht hat, die Systeme wirklich zu verwenden, zu evaluieren und zu vergleichen, und nicht allgemeines FUD zu verbreiten.
Wer verbreitet denn FUD ? Ich verfolge die DTC Mailinglist seit Tagen mit Argusaugen. Kann da nichts von FUD feststellen. Es kommen nur zahlreiche Kommentare von Leuten rein, die auch eine andere Sicht der Dinge haben. Und diese sollte man nicht ignorieren.
und auch die zukunftssicherste, dann erschlägt man alle Fliegen mit einer Klappe und kann problemlos systemd wählen.
Eine Unterstützung von cgroups für FreeBSD, OpenBSD, Hurd und Co kann auch nicht schaden.
Besser kann man nicht zusammenfassen, warum systemd NICHT gewählt werden sollte...
Der Satz ist ja ein Widerspruch in sich :-)
journald, logind, hostnamed, timedated, usw. sind eben exakt im alten Unix-Prinzip jeweils ein auf eine Funktionalität spezialisierte Services.
systemd ist leider hier ungünstigerweise sowohl der Name des Projekts als auch der Name eines der Dienste.
Gemeint ist hier eher, dass alle Tools in einem Paket kommen und so es etwas schwieriger wird, diese außerhalb der systemd-Umgebung zu nutzen (betrifft vor allem udev und logind).
So groß ist das Problem allerdings auch nicht, seitens Debian will man ja offensichtlich manche systemd Tools wie udev, logind, hostnamed u.a. auch dann nutzen, wenn Upstart das neue Init System wird.
Für eine Binärdistribution ist es auch überhaupt kein Problem diese Programme in separate Teile aufzuteilen. Bei Distributionen wie Gentoo wird das schon etwas schwieriger, aber ist auch machbar.
Zumal die Kompilierzeit für systemd als ganzes auch auf langsameren Maschinen vertretbar ist (auf meinem 4 Kerner braucht es ca. 4min pro Architektur).
Möglich, speziell auf einer Linux Seite dann aber doch eine sehr unglücklich gewählte Ausdruckweise.
Nur wenige Distributionen paketieren 1-zu-1 nach den Grenzen von Upstream Source Paketen.
Ich finde, dass eine Gruppe spezielisierter und zusammenarbeitender Dienste eben ein äußerst unixartiger Ansatz ist.
Das Paketieren ist der Job der Distribution. Nur wenn es ein einzelner großer Dienst wäre, stimmt die Aussage im Artikel. Es sind aber mehrere Dienste, die auch optional sind.
Ich fordere ein Abstimmung über Systemd, Upstart, Sysvinit und OpenRC unter den Debiananwendern. Manipulationen durch Firmen, die über Ihre Entwickler und deren an diese gebundenen Entscheidungen durchgedrückt werden könnten, wären so hundertprozentig vermeidbar.
Debian ist schließlich kein Entwicklerselbstzweck, die Anwender sollten entscheiden dürfen, welches Init-System in Zukunft in Debian standardmäßig verwendet wird.
Einfach einmal probieren. Vielleicht stimmen ja Millionen von Anwendern ab.
Na, wenn die Anwender selbst entscheiden sollen, dann reicht ja eine Auswahlmöglichkeit im Installer. Problem gelöst!
Du unterschätzt die geistigen und kognitiven Fähigkeiten der Nutzer.
... dann müssen aber noch immer alle hinter den Auswahlmöglichkeiten stehenden Systeme gepflegt werden, inkl. aller daraus resultierenden Folgen (sowohl Entwicklungs- als auch Benutzungstechnisch) ...
ich denke das wäre ein zu großer overhead fürs debian team.
...war eigentlich eher ironisch gemeint: wenn die User selbst entscheiden sollen, dann kann man gleich den Installer als Abstimmungswerkzeug nehmen. Beide Varianten, Abstimmung und Installer-Option, sind natürlich völliger Quatsch. Debian soll Upstart oder etwas anderes nehmen, nur nicht systemd, dessen Entwickler kFreeBSD, Hurd und sonstige Linux-Alternativen tot sehen wollen. Debian sollte diesen Vereinheitlichungsversuch nicht unterstützen. Und ich sage dies obwohl ich Canonical-Hasser bin...
Und du kannst deine Hand dafür ins Feuer legen, dass du (und viele andere) nicht durch Firmen manipuliert bist? Auch nicht ein bisschen?
Man könnte natürlich argumentieren, dass die Anwender ja evtl. Erfahrungen mit systemd/upstart/openrc haben, aber im Endeffekt sprechen wir hier von Debiananwendern und dort war weder das eine noch das andere bisher Standard. Natürlich gibt es Wechsler, aber ein großer Teil wird sich nie wirklich das eine oder das andere angeschaut haben.
Dadurch würde eine solche Abstimmung zu einem großen Teil zu einer "Glaubensfrage" mutieren und die Entscheidung für oder wider ein bestimmtes Init sollte keine Glaubensfrage sein (oder zumindest nicht wesentlich), sondern vor allem eine technische Frage (auch in Bezug auf den Aufwand der Debianmaintainer). Die "Millionen von Anwendern" werden aber genau davon keine Ahnung haben, wieso auch?
Ist das ein Typo?
cgoups -> cgroups?
Da ich weiß, dass hier bei ProLinux gerne auf Canonical eingedroschen wird, frage ich mich allerdings, wieso anscheinend keiner "Bauchschmerzen" bekommt, wenn die "Freie Community" eine Ami-Firma wie RedHat mit ihrer zwangsläufigen Nähe zu NSA und Co. an wesentlichen Teilen des Linux-Systems herumwerkeln lässt?
Allen Ernstes! Kann das einer erklären?
Red Hat arbeitet auch am Linux Kernel mit, genauso wie viele andere amerikanische Firmen. SELINUX stammt sogar von der NSA selbst.
Durchaus möglich, dass so Lücken im Linux-Ökosystem eingebaut wurden, aber warum ausgerechnet in systemd, wenn man doch Zugriff auf den "Kern" selbst hat?
Bisher hat niemand in von Red Hat beigesteuertem Code entsprechende Hinweise gefunden.
Die Red Hat-Entwickler wären IMO die ersten, die solchen Crap zuerst veröffentlichen und an den Pranger stellen würden.
Wir reden hier von einer Firma, die z.B. als einzige einen Nouveau-Entwickler einstellte, um Nvidias Einfluss auf diese Treiber loszuwerden, um endlich einen wirklich freien Treiber zu haben. Mit Cups werden sie eines Tages genauso verfahren, wenn Apple diesbezüglich einmal "ausflippen" sollte.
Wenn in freier Software etwas eingebaut wurde, dann eher in Gestalt eines bestimmtem Algorithmus in einer Art "Software-Komposition". So etwas wie z.B. den Debian openSSL-Fehler kann man nicht dauerhaft oder sehr lange vor der Community verstecken.
Und dann bitte auch gleich openSUSE miterwähnen, das von SUSE kontrolliert wird und selbst wiederum zur US-Firma Attachmate gehört.
Slackware sollte man auch nicht vergessen, auch dieses ist rein US-basiert.
Und Ubuntu als britische (!) Distribution dürfte da in punkto Geheimdienstpenetration kaum besser als die US-Distributoren dran sein.
Und nun, Herr Paranoia, zeigen Sie mir bitte die entsprechenden Beispiele von betroffenem Code, egal wo, in RHEL/CentOS/SL/Fedora, in SLES/openSUSE, in Ubuntu (Server), in Slackware. Ich warte.
Nun Herr K_tz, selbst wenn ich Beispiele von betroffenem Code zeigen könnte, könnten Sie ihn denn verstehen? Und um wieviel Millionen Zeilen Code geht es denn bei SELinux und systemd?
Red Hat arbeitet eng mit der NSA zusammen, das wird wohl niemand bestreiten. Der Red Hat Vorstandsvorsitzende ist ein hoher Ex-Militär und die NSA unternimmt alles erdenkliche, um das Netz zu kontrollieren. Vielleicht ist ja noch keine "Backdoor" in Linux-System eingebaut, aber wie einfach lässt sich das nachholen? (https://lkml.org/lkml/2013/9/5/212)
Und das war ein Red Hat-Entwickler, der versuchte den Code einzuschleusen...
Mir ist höchst unwohl dabei, wenn so was wichtiges wie das INIT-System aus diesen "dunklen Quellen" kommt. Firmen wie Apple, Google, Microsoft etc. konnten sich nicht dem Zugriff der NSA erwehren, warum sollte dann Red Hat, die die Zusammenarbeit ja direkt suchen, keine Hintertüren für die NSA einbauen?
Und bzgl. Nouveau denke ich, dass mit geringem Aufwand die Reputation in der Gemeinde enorm gesteigert wurde.
"Nun Herr K_tz, selbst wenn ich Beispiele von betroffenem Code zeigen könnte, könnten Sie ihn denn verstehen? Und um wieviel Millionen Zeilen Code geht es denn bei SELinux und systemd?"
Ich würde mich darum kümmern, das Leute diese Codeschnipsel zu sehen bekommen, die sich mit so etwas auskennen.
Es ist aber absolut unfair, irgendwelche Vermutungen in den Raum zu stellen, die durch nichts belegt sind. Das nennt sich eigentlich "Rufmord".
"Firmen wie Apple, Google, Microsoft etc. konnten sich nicht dem Zugriff der NSA erwehren,"
Solange man mit Closed Source-Code arbeitet, mag das so sein. Auch der NSA ist aber klar, dass der Sourcecode freier Software veröffentlicht werden wird. Das muss nicht heißen, dass in freier Software keine Backdoors enthalten sein können, nur müssen diese viel aufwendiger implementiert werden. Nichtsdestotrotz wird man, falls z.B Selinux eine solche Backdoor enthalten sollte, diese eines Tages an Ihrer bloßen Funktionsfähigleit erkennen. Linux protokolliert ja im allgemeinen sehr gut, was das eigene System so anstellt.
Trotzdem genügt auch hier nicht der bloße Verdacht. Irgendetwas Handfestes, das einen Verdacht begründet, muss schon vorhanden sein, Auffälligkeiten im Code, Bugs in der Funktionsfähigkeit, kompliziert zu behebende Sicherheitslücken.
Falls Dein bisher haltloser Verdacht gegenüber Linuxfirmen tatsächlich wahr wäre, so wäre jedes Linux "verseucht". Auch der Kernel-Chef ist ja mittlerweile US-Staatsbürger. Wenn Red Hat "fällt", fallen unter Umständen auch die "Anderen".
Und bitte nicht vergessen: Auch Festplatten- und Routerhersteller sowie Netzwerkausrüster und Computer-Hardwarehersteller scheinen in dem NSA-Geflecht zumindest Opfer gewesen zu sein. Das heißt, dass Dein Computer, insofern er nach etwa 1995 gebaut wurde, schon alles hardware- und firmwaremäßig enthalten könnte, was man bräuchte, um auf das zuzugreifen, was man von Dir, mir und Millionen anderer Computernutzer gerne lesen möchte. Da hilft im Prinzip dann nur noch die Abkopplung des eigenen Rechners von öffentlichen, unsicheren Netzwerken wie dem Internet. Fürden Fall, dass Du Dich dazu entschließen solltest, sage ich schon einmal "Auf Wiedersehen".
Denn warum sollten Organisationen wie die NSA mit Ihren Aktionen erst bei der Software ansetzen? Ich würde auf der Stufe darunter aktiv werden, eben auf der Stufe der Hard- und Firmware (Mainboard-Bios, Steckkarten-Bios und - RAM, Festplattenfirmware, usw.). Dies wäre ungeheuer effektiv. Eine so mächtiges Land wie die USA könnte dies tatsächlich hinbekommen (haben). Das hätte auch den netten Vorteil, dass die meisten Betroffenen niemals merken würden, dass sie ausgehorcht wurden.
Aber wie schon gesagt: Ein Hätte, Wäre, Könnte genügt nicht zur Anklage.
"...Ein Hätte, Wäre, Könnte genügt nicht zur Anklage..."
Es geht nicht um eine Anklage, sondern darum, welches INIT-System die wohl wichtigste "unabhängige, freie Community" wählen wird.
"Denn warum sollten Organisationen wie die NSA mit Ihren Aktionen erst bei der Software ansetzen?"
Tun sie ja nicht, sie setzen auf allen möglichen Ebenen an, Software, Hardware, Firmware, Unterseekabel, Wanzen, Drohnen etc. Und hier weiter gedacht: Warum sollten sie unser Linux-System aussparen, wenn es da schon die Möglichkeiten der direkten Mitarbeit und Einflussnahme gab/gibt?
"Falls Dein bisher haltloser Verdacht gegenüber Linuxfirmen tatsächlich wahr wäre, so wäre jedes Linux "verseucht"."
Es geht nicht um einen Verdacht gegenüber "Linux-Firmen", sondern darum, wie andere Leser hier diese Nähe von Red Hat zur NSA sehen und bewerten, angesichts der Tatsache, dass die Wahl des INIT-Systems durch Debian von durchaus weitreichender Bedeutung sein wird. Hier wird immer gerne auf Canonical eingedroschen, aber niemand scheint sich Gedanken um eine Firma wie Red Hat zu machen, das finde ich einseitig.
Aber vielleicht mache ich mir unnötige Sorgen und Systemd, in Kombination mit SELinux ist für die Experten hier und dich völlig transparent, weil ihr den Source-Code dazu vollkommen versteht und schon durchgelesen habt?
"Aber vielleicht mache ich mir unnötige Sorgen und Systemd, in Kombination mit SELinux ist für die Experten hier und dich völlig transparent, weil ihr den Source-Code dazu vollkommen versteht und schon durchgelesen habt?"
Nein, natürlich nicht.
Ich habe ebenfalls Vorbehalte gegenüber Systemd. IMO ist es nicht wesentlich schneller als Sysvinit (unter openSUSE wird die "Schnelligkeit" von Systemd u.a. dadurch gesteigert, dass der X-Server noch vor dem Herstellen der Netzwerkverbindung hochfährt; bei einem Vergleich von Sysvinit-openSUSE 11.4 mit Systemd-openSUSE 13.1) und die zwei, drei Dinge, die Systemd besser macht, könnte man auch versuchen, in Sysvinit zu integrieren.
Zudem mag ich den momentanen Gnome3-Standard in Debian nicht besonders, und wenn das systemd-abhängige Gnome3 dadurch gegenüber einer GUI wie Xfce unter Debian endgültig ins Hintertreffen gerät, so wäre mir dies sehr recht.
Ich kann mich alledings auch nicht für Upstart erwärmen, es ist im Vergleich zu Sysvinit IMO kein wirklicher Fortschritt.
Fazit: Meine Antwort zu Systemd und Upstart: Nein.
Kubuntu und Linux Mint setzen systemd in ihren aktuellen Distris ein. Beide sind Ubuntu-Paket-kompatibel. Bei Ubuntu ist systemd seit April 2013 in den Repos. Siehe auch hier:
https://en.wikipedia.org/wiki/Systemd#Adoption
Ich habe LM16 MATE jetzt auf zwei Maschinen installiert. Läuft prima.
Ich finde an keiner Stelle einen Hinweis, dass das aktuelle Kubuntu auf systemd setzt. Gibt es da eine Quelle? Nur weil es seit April/2013 in den Repos ist bedeutet das nicht, dass es auch benutzt wird. Steht auch so im Wiki: Enabled by default -> no
Ich habe meine Maschinen auf Kubuntu 13.10 aktualisiert und seitdem laufen systemd-udevd und systemd-logind. Ohne mein Zutun, bereitgestellt durch das Paket "systemd-services".
Nach dem ich Kubuntu 14.04 in einer VM installiert habe, kam ich zu noch einem anderen Ergebnis. Das nutzt systemd-logind und systemd-shim (this package emulates the systemd function that are required to run the systemd helpers without using the init service). Was immer das bedeutet. Allerdings und das hatte ich auch erwartet, nutzt es Upstart.