Durc Schnittstellen nach draußen und Programme die für spezifische Sachen diese verwenden.
Sorry, das ist absolut vages, unspezifisches Geblubber. Wie willst Du cgroups ersetzen, die systemd für die Überwachung von Daemons nutzt (und bitte sag jetzt nicht "Jails", das ist etwas vollkonmen anderes)? Wie willst Du etwas wie udev auch nur ansatzweise sinnvoll portabel abstrahieren?
Man vermeidet ein monolitisches Monster wie systemd das sich nicht auf nicht-Linuxsystem verwenden lässt.
Systemd ist nicht monolithisch. Der systemd-Quelltext kompiliert dieser Tage zu über 60 Binaries, von denen viele auch außerhalb von Systemd nützlich sind. Abgesehen davon hast Du immer noch nicht erklärt, wieso es ein Problem sein soll, dass systemd nur unter Linux funktioniert. Jedes andere OS hat sein eigenes init, z. B. SMF unter Solaris (auch nicht portabel), launchd von OS X hattest Du schon erwähnt, die BSDs haben auch ihre eigenen init-Systeme. Wem wurde es also nützen, wenn systemd portabel wäre? Praktisch niemandem. Die Kosten wären dagegen erheblich: man müsste eine Abstraktionsschicht für jedes der (zahlreichen) Linux-Interfaces entwickeln, die systemd nutzt, was zu Komplexität, Bugs und jeder Menge vertaner Zeit führen würde, die dann nicht mehr für die Entwicklung neuer Features und Optimierungen zur Verfügung steht -- ein schlechter Tradeoff.
Ein Programm pro Aufgabe, lose verbunden, nicht eines für alles. Unix-philosophie.
Unix-Philosophie ist heute vor allem nur noch eins: eine Ausrede dafür, gegen alles zu sein was nicht schon seit 20 Jahren so gemacht wird.
Was an Systemd ist denn nicht monolithisch, ein Haufen Projekte und Tasks wurde vereint, "weil es da hingehört". Das Problem meiner Meinung nach das Systemd die Freiheit vieler Open Source Projekte einschränkt. Wieso sollen Gnome Nutzer unbedingt Linux Nutzer werden? Es gab mal eine Trennung bzw. Abstraktion, die mit systemd völlig ausgehebelt wird.
Die Unix Philosophie ist vorallem das: Linux ist kein Unix hat mit den Prinzipien zunehmend nichts zu tun. Ein netter Artikel[2] dazu.
Äh, alles? systemd ist eine Sammlung von verschiedenen Daemons und Tools, die sinnvoll miteinander zusammenarbeiten: systemd zur Verwaltung von Diensten sowie Boot und Shutdown, systemd-journald fürs Logging, systemd-logind für die Seats, systemd-hostnamed für den Hostnamen, systemd-udevd für die Verwaltung der Hardware, systemd-timedated für die Uhr...
ein Haufen Projekte und Tasks wurde vereint, "weil es da hingehört".
"Vereint" heißt hier in erster Linie, dass diese Programme im gleichen git-Repository entwickelt werden. Das erleichtert Entwicklung, Deployment und Code-Wiederverwendung. Ganz zu schweigen davon, dass die weitaus meisten Betriebssysteme komplett in einem einzigen Repository entwickelt werden, z. B. die BSD- und System-V-Abkömmlinge und überhaupt so ziemlich jedes andere Betriebssystem. Nur unter GNU/Linux hat man diese merkwürdige Einstellung, dass alles getrennt voneinander entwickelt und released muss, nur damit hunderte Distributionen dann daraus wieder irgendeinen Flickenteppich zusammenstückeln können, den man irgendwie als Betriebssystem durchgehen lassen kann.
Die Unix Philosophie ist vorallem das: Linux ist kein Unix hat mit den Prinzipien zunehmend nichts zu tun.
Ehrlich gesagt ist mir das Latte. Die Hardware ist um viele Größenordnungen schneller und vor allem viel komplexer (Hotplug, Plug'n'Play etc. pp.) als zu der Zeit, als Unix entstanden ist. Die Nutzerinteraktion ist vollkommen anders, oder hast Du Dein Posting von einer Shell aus abgesandt? Und heute werden Computer für Anwendungen genutzt, von denen damals niemand zu träumen gewagt hätte, es gibt vollkommen neue Gerätebauweisen wie Smartphones und Tablets. Genauso umwälzend sind Veränderungen auf dem Gebiet der Software. Techniken wie shared libraries (und die höheren Abstraktionen, die dadurch möglich sind) und moderne Programmiersprachen machen heute Projekte handhabbar, an deren Komplexität man damals gnadenlos gescheitert wäre. Mir ist vollkommen schleierhaft, wie jemand ernsthaft glauben kann, dass irgendeine Philosophie, die sich vor Jahrzehnten irgendjemand aus den Fingern gesogen hat, heute noch irgendeine Relevanz besitzt. Mir persönlich scheint das mehr mit Religion als mit Technik zu tun zu haben. Denn in der Technik gilt eben: Wer nicht mit der Zeit geht, geht mit der Zeit.
Ich habe den Artikel http://www.pappp.net/?p=969 gelesen und es ist einfach: ich mag die neuen Wege von systemd (und ähnliche Projekte) nicht, und deswegen ist es schlecht. Verpackt in einer "UNIX Philosophie".
Linux ist nicht UNIX und ich und andere interessiert es nicht was andere Systeme verwenden. Ich finde systemd wesentlich besser als die Init-Scripte und ich hoffe, dass sich systemd durchsetzen wird.
Mich interessiert es nicht was die *BSD verwenden und ob sie Gnome als Desktop wollen. Die *BSD können ja auch dbus und systemd nach BSD portieren.
Wenn sich der Linux Desktop durch dbus und systemd besser bedienen lässt, dann bin ich 200% dafür. Und z.Z. sieht es danach aus. Linux Server sind sowieso so minimal, denen sollte die ganze Entwicklung überhaupt nichts angehen.
Wenn sich der Linux Desktop durch dbus und systemd besser bedienen lässt, dann bin ich 200% dafür. Und z.Z. sieht es danach aus. Linux Server sind sowieso so minimal, denen sollte die ganze Entwicklung überhaupt nichts angehen.
Systemd deckt alle Anwendungsgebiete unter Linux ab, Server sind da keinesfalls ausgenommen.
> Systemd ist nicht monolithisch. Der systemd-Quelltext kompiliert dieser Tage zu über 60 Binaries
Die Anzahl an Binaries sagt nichts über das monolithische Design aus. Das ist dir auch selbst bewusst den wie du im folgenden Satz schriebst
> wieso es ein Problem sein soll, dass systemd nur unter Linux funktioniert
Weil systemd keine Insel ist und das was es umgibt, drauf aufsetzt, es verwendet, sich einhängt, es umgibt auch auf anderen Systemen zum tragen kommt.
Und mit nichten ist das nur ein Nicht-Linux Problem. Nun gehts schon soweit das DBus in den Kernel soll. Ich glaub mich tritt ein Elch.
> Wem wurde es also nützen, wenn systemd portabel wäre?
Wer braucht schon Portabilität. Dies ist Sparta! äh Linux!
> Die Kosten wären dagegen erheblich
Ordentliches Design zahlt sich langfristig immer aus. Der Aufwand Teile auf andere Platformen zu bringen oder auch Teile durch Besseres zu ersetzen wird sowieso nicht von jenen geleistet die viel zu sehr beschäftigt sind andere Gruppen auszuschliessen.
Einen hab ich noch. 99% aller Linux Systeme haben schon ein anderes init und werden wohl wuch nie auf systemd wechseln. http://www.elinux.org/Android_Booting
Das hat politische Gründe. systemd steht unter der LGPL, und GPL- und LGPL-Software erlaubt Google im Android-Userspace nicht. Eine Aussage über die technische Qualität von systemd lässt sich daraus nicht ableiten.
Das Android init System ist zunächst mal genau das und nicht mehr, ein init System.
Die weitaus meisten Funktionen in systemd kann man mit configure-Switches deaktivieren.
KISS. Ein technischer Aspekt.
KISS ist kein technischer Aspekt, sondern eine Binsenweisheit. Natürlich sind einfache Systeme ceteris paribus erstmal besser als komplexe. Aber die ceteris-paribus-Annahme trifft eben nicht zu: systemd funktioniert besser und zuverlässiger als die Alternativen. Auf "simple" trifft so etwas ähnliches zu wie MJG es mal über "lightweight" gesagt hat:
To a first approximation, when someone says "Lightweight" what they mean is "I don't understand the problems that the alternative solves".
Die Anzahl an Binaries sagt nichts über das monolithische Design aus.
Ah ja. Kannst Du dann bitte mal erklären, was Du unter einem monolithischen Design verstehst? Es hat nämlich offensichtlich nichts mit der Definition zu tun, die mir geläufig ist...
Das ist dir auch selbst bewusst den wie du im folgenden Satz schriebst > wieso es ein Problem sein soll, dass systemd nur unter Linux funktioniert
Portabilität und Modularität sind vollkommen unabhängige Eigenschaften.
Weil systemd keine Insel ist und das was es umgibt, drauf aufsetzt, es verwendet, sich einhängt, es umgibt auch auf anderen Systemen zum tragen kommt.
Und mit nichten ist das nur ein Nicht-Linux Problem.
Doch, genau das ist es: ein Nicht-Linux-Problem. systemd ist nicht die Heilsarmee, und wenn andere Systeme die gleiche Funktionalität bieten wollen, müssen sie das eben selber machen. Und dabei können sie dann auch gern all die Features benutzen, die das jeweilige Betriebssystem zur Verfügung stellt: ContractFS und Zones unter Solaris, Jails und kqueue unter FreeBSD und all dieses Zeugs halt. Sie tun es übrigens bereits. Wie erwähnt ist Solaris' SMF nicht portabel (wegen ContractFS), und FreeBSD init auch nicht (z. B. wegen revoke(2)). Wieso soll ausgerechnet systemd hier die große Ausnahme stellen?
Nun gehts schon soweit das DBus in den Kernel soll. Ich glaub mich tritt ein Elch.
Nein, davon war nie die Rede. Du beziehst Dich wohl auf das hier. Zitat:
Our goal (and I use "goal" in a very rough term, I have 8 pages of scribbled notes describing what we want to try to implement here), is to provide a reliable multicast and point-to-point messaging system for the kernel, that will work quickly and securely.
Da steht nichts von D-Bus. Dass im Zusammenhang mit diesem Feature oft von D-Bus die Rede ist liegt schlicht daran, dass D-Bus vermutlich der wichtigste Nutzer dieses Interfaces sein wird.
> Wem wurde es also nützen, wenn systemd portabel wäre? Wer braucht schon Portabilität. Dies ist Sparta! äh Linux!
Keine Antwort ist auch eine Antwort.
Ordentliches Design zahlt sich langfristig immer aus.
systemd ist ordentlich designed. Es war keine Schlampigkeit, sondern eine bewusste Entscheidung der Entwickler, Portabilität nicht zu berücksichtigen, weil es a) nicht mit vertretbarem Aufwand möglich ist, diese Funktionalität portabel zu implementieren (nein, dein Geblubber von vorhin hat diese Aussage nicht widerlegt) und weil es b) nicht einmal dann sinnvoll wäre, wenn es ginge.
> Portabilität und Modularität sind vollkommen unabhängige Eigenschaften.
Das zweite für zum Ersten.
> Doch, genau das ist es: ein Nicht-Linux-Problem.
Android ist Linux.
> Wieso soll ausgerechnet systemd hier die große Ausnahme stellen?
Weil systemd mehr als nur init umfasst und kein autarkes system ist.
Das unvermögen in diesem Bereich mit anderen Interessensgruppen zusammenzuarbeiten ist der größte Hehmschuh. Warum wird den kategorisch im Vorfeld jeder Patch der von anderen Gruppierungen kommt abgewiesen? Wie wäre es den mal mit etwas Kooperationsbereitschaft?
Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging complex code that is complex, long, and unreadable.
Und das trifft auf systemd zu. systemd ist aus zahlreichen Daemons aufgebaut, die über verschiedene Schnittstellen ("well-defined interfaces") miteinander kommunizieren, und die durch Alternative Implementierungen ersetzt werden können ("parts of the program can be replaced"), siehe Spalte "Known Other Implementations" im Link.
> Portabilität und Modularität sind vollkommen unabhängige Eigenschaften. Das zweite für zum Ersten.
Das ist vollkommener Quatsch.
Android ist Linux.
Und? Sie könnten systemd ja verwenden, sie wollen nur nicht, wegen der Lizenz.
Weil systemd mehr als nur init umfasst und kein autarkes system ist.
Immer noch kein Argument, wieso es portabel sein müsste.
Das unvermögen in diesem Bereich mit anderen Interessensgruppen zusammenzuarbeiten ist der größte Hehmschuh. Warum wird den kategorisch im Vorfeld jeder Patch der von anderen Gruppierungen kommt abgewiesen?
Zum 100sten mal: weil diese Art von Funktionalität nicht mit vertretbarem Aufwand portabel implementierbar ist. Und wenn Du Ahnung von der Technik hättest, würdest Du das langsam auch mal einsehen.
Und das wiederlegt deine Aussage es wäre ausschließlich ein Nicht-Linux Problem gründlich. Zähle Android, Ubuntu, debian zusammen und systemd ist ein 0.1% Nischensystem. Schade weil es nicht sein müsste.
> Sie könnten systemd ja verwenden
Warum sollten sie? systemd als Eierlegendewollmilchsau gibt keinen Mehrwert dafür jede Menge Nachteile wie Portabilität und Komplexität zB.
>> Weil systemd mehr als nur init umfasst und kein autarkes system ist.
> Immer noch kein Argument, wieso es portabel sein müsste.
Dann kann ich dir auch nicht helfen. Augen zu und durch.
> weil diese Art von Funktionalität nicht mit vertretbarem Aufwand portabel implementierbar ist.
Erstens bist nicht du derjenige der das Implementiert und zweitens ist es eine Null-OP gründliches Design vorausgesetzt. Das es das momentan nicht ist, laut deiner Feststellung, bedarf dann Nachbesserungen die sich langfristig jedoch auszahlen würden.
Mir drängt sich hier doch der Eindruck auf, jemand will mit aller macht "seinen Code" verteidigen. Blockwart nennt man das.
Und das wiederlegt deine Aussage es wäre ausschließlich ein Nicht-Linux Problem gründlich.
Nein. Es ging an dieser Stelle um Portabilität, aber Android würde auch dann nicht systemd verwenden, wenn es portabel wäre, weil es unter der LGPL steht. Zudem verwendet Android auch andere unportable APIs wie z. B. Wakelocks. Mangelnde Portabilität sind also nachweislich kein Problem für Android.
Warum sollten sie? systemd als Eierlegendewollmilchsau gibt keinen Mehrwert
Systemd ist keine Eierlegende Wollmilchsau. Wie gesagt, das Design ist modular und sehr konfigurierbar. Wenn Du irgendetwas nicht willst, dann benutze die entsprechenden Switches des configure-Scripts. Und der Mehrwert ist erheblich, wie jeder weiß, der sich mal fünf Minuten mit dem Thema beschäftigt hat.
Dann kann ich dir auch nicht helfen. Augen zu und durch.
Stimmt, das kannst Du in der Tat nicht, weil Deine "Argumente" einfach keinen Sinn ergeben.
Erstens bist nicht du derjenige der das Implementiert und zweitens ist es eine Null-OP gründliches Design vorausgesetzt.
Nein, gutes Design und Portabilität haben immer noch nichts miteinander zu tun, auch wenn Du diesen Quatsch jetzt noch 100mal wiederholst. Ein Design ist gut, wenn es die gewünschten Ziele mit einem Minimum an Komplexität erreicht. Dein Problem ist, dass Dir die vom systemd-Projekt gewählten Ziele, die Portabilität nicht einschließen, nicht passen, und deswegen erzählst Du hier irgendwelchen Quatsch von schlechtem Design. Außerdem hast Du immer noch nicht erklärt, wie man die von systemd gebotene Funktionalität ansatzweise portabel implementieren soll, vermutlich, weil es schlicht und einfach nicht praktikabel ist, dir jedoch die technischen Kenntnisse fehlen, um das einzusehen. Dunning-Kruger-Effekt lässt grüßen...
Mir drängt sich hier doch der Eindruck auf, jemand will mit aller macht "seinen Code" verteidigen.
Und das sagt ausgerechnet derjenige, der im Verlauf des ganzen Threads nicht in der Lage war, ein einziges logisches Argument zu bringen und sich stattdessen ständig Plattitüden über "Unix-Philosophie" und ähnlichen Quatsch von sich gibt? Sorry, die Diskussion mit Dir ist vollkommen sinnlos. Wenn Du weiter diskutieren willst, arbeite an Deinem IQ, und bis dahin werde ich mir den Quatsch hier sparen.
> Du kannst ja mal zeigen, wie all das ohne Linux-spezifische APIs gehen soll
Durc Schnittstellen nach draußen und Programme die für spezifische Sachen diese verwenden.
> und vor allem wo da der Vorteil liegen soll.
Man vermeidet ein monolitisches Monster wie systemd das sich nicht auf nicht-Linux system verwenden lässt.
Ein Programm pro Aufgabe, lose verbunden, nicht eines für alles. Unix-philosophie.
Was an Systemd ist denn nicht monolithisch, ein Haufen Projekte und Tasks wurde vereint, "weil es da hingehört". Das Problem meiner Meinung nach das Systemd die Freiheit vieler Open Source Projekte einschränkt. Wieso sollen Gnome Nutzer unbedingt Linux Nutzer werden? Es gab mal eine Trennung bzw. Abstraktion, die mit systemd völlig ausgehebelt wird.
Die Unix Philosophie ist vorallem das: Linux ist kein Unix hat mit den Prinzipien zunehmend nichts zu tun. Ein netter Artikel[2] dazu.
[1] http://en.wikipedia.org/wiki/Cgroups
[2] Artikel:http://www.pappp.net/?p=969
Ich habe den Artikel http://www.pappp.net/?p=969 gelesen
und es ist einfach: ich mag die neuen Wege von systemd (und ähnliche Projekte) nicht, und deswegen ist es schlecht. Verpackt in einer "UNIX Philosophie".
Linux ist nicht UNIX und ich und andere interessiert es nicht was andere Systeme verwenden. Ich finde systemd wesentlich besser als die Init-Scripte und ich hoffe, dass sich systemd durchsetzen wird.
Mich interessiert es nicht was die *BSD verwenden und ob sie Gnome als Desktop wollen. Die *BSD können ja auch dbus und systemd nach BSD portieren.
Wenn sich der Linux Desktop durch dbus und systemd besser bedienen lässt, dann bin ich 200% dafür. Und z.Z. sieht es danach aus. Linux Server sind sowieso so minimal, denen sollte die ganze Entwicklung überhaupt nichts angehen.
> Systemd ist nicht monolithisch. Der systemd-Quelltext kompiliert dieser Tage zu über 60 Binaries
Die Anzahl an Binaries sagt nichts über das monolithische Design aus. Das ist dir auch selbst bewusst den wie du im folgenden Satz schriebst
> wieso es ein Problem sein soll, dass systemd nur unter Linux funktioniert
Weil systemd keine Insel ist und das was es umgibt, drauf aufsetzt, es verwendet, sich einhängt, es umgibt auch auf anderen Systemen zum tragen kommt.
Und mit nichten ist das nur ein Nicht-Linux Problem. Nun gehts schon soweit das DBus in den Kernel soll. Ich glaub mich tritt ein Elch.
> Wem wurde es also nützen, wenn systemd portabel wäre?
Wer braucht schon Portabilität. Dies ist Sparta! äh Linux!
> Die Kosten wären dagegen erheblich
Ordentliches Design zahlt sich langfristig immer aus. Der Aufwand Teile auf andere Platformen zu bringen oder auch Teile durch Besseres zu ersetzen wird sowieso nicht von jenen geleistet die viel zu sehr beschäftigt sind andere Gruppen auszuschliessen.
Einen hab ich noch. 99% aller Linux Systeme haben schon ein anderes init und werden wohl wuch nie auf systemd wechseln. http://www.elinux.org/Android_Booting
Das hat politische Gründe. systemd steht unter der LGPL, und GPL- und LGPL-Software erlaubt Google im Android-Userspace nicht. Eine Aussage über die technische Qualität von systemd lässt sich daraus nicht ableiten.
> politische Gründe
Das Android init System ist zunächst mal genau das und nicht mehr, ein init System. KISS. Ein technischer Aspekt.
> was Du unter einem monolithischen Design verstehst?
http://en.m.wikipedia.org/wiki/Unix_philosophy#section_2
> Portabilität und Modularität sind vollkommen unabhängige Eigenschaften.
Das zweite für zum Ersten.
> Doch, genau das ist es: ein Nicht-Linux-Problem.
Android ist Linux.
> Wieso soll ausgerechnet systemd hier die große Ausnahme stellen?
Weil systemd mehr als nur init umfasst und kein autarkes system ist.
Das unvermögen in diesem Bereich mit anderen Interessensgruppen zusammenzuarbeiten ist der größte Hehmschuh. Warum wird den kategorisch im Vorfeld jeder Patch der von anderen Gruppierungen kommt abgewiesen? Wie wäre es den mal mit etwas Kooperationsbereitschaft?
>> Android ist Linux.
> Und?
Und das wiederlegt deine Aussage es wäre ausschließlich ein Nicht-Linux Problem gründlich. Zähle Android, Ubuntu, debian zusammen und systemd ist ein 0.1% Nischensystem. Schade weil es nicht sein müsste.
> Sie könnten systemd ja verwenden
Warum sollten sie? systemd als Eierlegendewollmilchsau gibt keinen Mehrwert dafür jede Menge Nachteile wie Portabilität und Komplexität zB.
>> Weil systemd mehr als nur init umfasst und kein autarkes system ist.
> Immer noch kein Argument, wieso es portabel sein müsste.
Dann kann ich dir auch nicht helfen. Augen zu und durch.
> weil diese Art von Funktionalität nicht mit vertretbarem Aufwand portabel implementierbar ist.
Erstens bist nicht du derjenige der das Implementiert und zweitens ist es eine Null-OP gründliches Design vorausgesetzt. Das es das momentan nicht ist, laut deiner Feststellung, bedarf dann Nachbesserungen die sich langfristig jedoch auszahlen würden.
Mir drängt sich hier doch der Eindruck auf, jemand will mit aller macht "seinen Code" verteidigen. Blockwart nennt man das.
Außerdem hast Du immer noch nicht erklärt, wie man die von systemd gebotene Funktionalität ansatzweise portabel implementieren soll, vermutlich, weil es schlicht und einfach nicht praktikabel ist, dir jedoch die technischen Kenntnisse fehlen, um das einzusehen. Dunning-Kruger-Effekt lässt grüßen...Und das sagt ausgerechnet derjenige, der im Verlauf des ganzen Threads nicht in der Lage war, ein einziges logisches Argument zu bringen und sich stattdessen ständig Plattitüden über "Unix-Philosophie" und ähnlichen Quatsch von sich gibt? Sorry, die Diskussion mit Dir ist vollkommen sinnlos. Wenn Du weiter diskutieren willst, arbeite an Deinem IQ, und bis dahin werde ich mir den Quatsch hier sparen.