Also ich finde es unnötig, was systemd und co da machen ist nichts anderes das Rad neu zu erfinden und die Codebasis auf zu blähen und ein System unnötig zu verkomplizieren. Ein mit Grund für mich von Debian und co zu BSD (OpenBSD) zu wechseln.
Debian setzt systemd (noch) nicht ein, es ist lediglich im Repository. Ob Debian überhaupt systemd einsetzen wird oder doch lieber upstart nimmt oder gar sysv-init treu bleibt, ist lange noch nicht entschieden.
Debian wird sich dem nicht wirklich widersetzen können, Gnome z.B. hat komplett auf Systemd umgestellt. Letztendlich verfügt Debian nicht über das Know-How und die Entwicklerressourcen, um hier langfristig sein eigenes Süppchen kochen zu können.
Das Problem sehe ich auch darin, wenn SystemD immer tiefer in Gnome integriert wird. Es frisst sich da wie Krebs hinein und kann irgendwann nicht mehr entfernt werden. Irgendwann werden es wohl alle einsetzen müssen, egal ob sie es brauchen oder nicht...
das ist das Problem hinter systemd, mittlerweile setzen fast alle darauf. durch irgendwelche Abhängigkeiten ist man früher oder später gezwungen es zu nutzen.
diese umgreifende Featuritis und Automatisierung ist mittlerweile nervig. Ging es früher darum, dass die Tools möglichst gut aufeinander abgestimmt sind, wird jetzt alles in eins gepackt. Heute bekommt man schon komische Blicke, wenn man das bewährte LVM + FS einem Featuremonster wie BtrFs oder zfs vorzieht.
Soweit ich das verstanden habe ist das, zumindest derzeit, noch kein Problem, es werden lediglich einige D-Bus Schnittstellen benutzt, die z.B. von systemd bereit gestellt werden.
Von Unerkannt am Mo, 16. September 2013 um 12:14 #
Wie es aussieht braucht man SystemD damit Gnome 3.8 richtig läuft. Es geht wohl über ein paar optionale D-Bus-Schnittstellen hinaus. Bei Ubuntu und Gentoo hat man es wohl versucht, Gnome ohne SystemD zu bekommen und ist gescheitert. Gnome und SystemD greifen hier direkt die Wahlfreiheit der Nutzer an. Das ist eine Schweinerei.
Wie es aussieht braucht man SystemD damit Gnome 3.8 richtig läuft. Es geht wohl über ein paar optionale D-Bus-Schnittstellen hinaus. Bei Ubuntu und Gentoo hat man es wohl versucht, Gnome ohne SystemD zu bekommen und ist gescheitert.
Ubuntu wird nur einen kleinen Teil von systemd verwenden ("logind"). Der ist tatsächlich Teil von systemd, erzwingt aber nicht den Wechsel des init-Prozesses.
Von Polynomial-C am Mo, 16. September 2013 um 13:07 #
Das ist aber auch nur bis systemd-204 möglich. Alle neueren Versionen haben logind direkt in systemd integriert (AFAIK kein eigens tool mehr). Somit kann ubuntu nicht auf eine neuere Version von systemd umstellen, was aus sicherheitstechnischer Sicht recht problematisch werden kann.
Von Anonymous Coward am Di, 17. September 2013 um 00:20 #
Das ist aber auch nur bis systemd-204 möglich. Alle neueren Versionen haben logind direkt in systemd integriert (AFAIK kein eigens tool mehr).
Ich habe gerade, um diese Behauptung zu überprüfen, den Quelltext von systemd 207 heruntergeladen. Es ist problemlos möglich, systemd-logind zu bauen, also hör auf, Dir irgendwelchen Mist auszudenken.
Es geht wohl über ein paar optionale D-Bus-Schnittstellen hinaus.
Ah, kann sein. Wie gesagt habe ich da keinen direkten Einblick, das war meine Interpretation von entsprechende Kommentaren von GNOME Entwicklern in diversen Kommentarbereichen.
Gnome und SystemD greifen hier direkt die Wahlfreiheit der Nutzer an
Naja, nur eingeschränkt. Wenn GDM bestimme Vorraussetzungen hat, die man nicht erfüllen möchte, kann man z.B. LightDM oder andere Alternativen einsetzen. Selbes für GNOME Shell, usw.
Ich vermute einmal, dass die oben erwähnten Gnome 3.8-"Features" (Powermanagement, GDM, Multi Seat) unter einem Ubuntu mit Gnome 3.8 ohne Systemd nicht funktionieren. "Systemd-services" steht übrigens in den Recommends und wird demzufolge anscheinend automatisch mitinstalliert. Gnome 3 befindet sich mittlerweile sowieso in Ubuntu Universe, von daher wird das Shuttleworth und Co. hochgradig egal sein.
Von Polynomial-C am Mo, 16. September 2013 um 13:21 #
ubuntu hat entweder noch nicht gnome-3.8 Pakete verfügbar, oder (wahrscheinlichere These) sie bleiben bei systemd-204, weil man dort logind ohne den Rest von systemd verwenden kann. Das geht allerdings seit systemd-205 nicht mehr (siehe mein Kommentar weiter oben).
Von Unerkannt am Mo, 16. September 2013 um 11:55 #
Es gibt ja durchaus noch Distributionen die ohne systemd kommen. Ich kann dich verstehen. Man ist trotzdem noch nicht gezwungen das Linux Boot ganz zu verlassen.
Können die Gegner von systemd auch ein paar Fakten liefern, weil bisher kommt immer nur polemisches "Rad neu zu erfinden" "Codebasis auf zu blähen" "Krebs" u.ä. Klingt nach "es ist neu deswegen mag ich es nicht" oder "es ist von Lennart Poettering, deswegen mag ich es nicht".
The Biggest Myths http://0pointer.de/blog/projects/the-biggest-myths.html
* Myth: systemd is monolithic * Myth: systemd is not modular * Myth: systemd was created as result of the NIH syndrome * Myth: systemd is bloated * Myth: systemd being Linux-only is not nice to the BSDs * etc.
Ich denke wenn Morgen deine Lieblingsdistribution auf systemd umgestellt wird, würdest du als Nutzer überhaupt nichts merken (bis auf vllt. einen schnelleren Bootvorgang).
Ich finde dass diese Datei für systemd wesentlich besser ist als ein 100 Zeilen langes sys-v Script (ist mein erstes, eigenes Script dass ich nach 10 Minuten lesen der systemd Dokumentation erstellt habe):
Meine Lieblingsdistribution wird nicht auf systemd wechseln...
Unabhängig davon ist es auf jeden Fall schlecht, dass systemd eine Abhängigkeit von Gnome ist. Das bedeutet, dass jede Distribution, die Gnome verwenden will, auch systemd nehmen muss. Das ist nicht in Ordnung!
Von Anonymous Coward am Di, 17. September 2013 um 14:41 #
Unabhängig davon ist es auf jeden Fall schlecht, dass systemd eine Abhängigkeit von Gnome ist. Das bedeutet, dass jede Distribution, die Gnome verwenden will, auch systemd nehmen muss. Das ist nicht in Ordnung!
Ach, wieso denn nicht? Und viel interessanter: Was wäre denn die Alternative? systemd wird gebraucht, um die betreffenden Features umzusetzen. Ganz gewiss keine Alternative ist es, diese Features dann gar nicht umzusetzen.
Wird bestimmt lustig, wenn systemd versucht, meine sshfs-Mounts an unterschiedlichen Ports mit unterschiedlichen Usern per Keyfile und mit ’ne Handvoll spezieller Optionen zu mounten.
LABEL=home, LABEL=root und LABEL=swap bekommt jedes halbwegs ausgewachsene Shellscript hin, dass systemd das kann, ist klar, aber ansonsten?
systemd hat für mich nur Vorteile, aber ich sehe auch – annders als Lennart – die Realität.
Ich mag systemd und setze es selbst ein, aber, es wird zu großen Teilen von Red Hat entwickelt, einer US Firma und ist (neben dem Linux Kernel selbst) vermutlich die beste Möglichkeit Schlupflöcher in das System einzubauen. Das ist momentan der wesentliche Grund, der mir bei systemd Bauchschmerzen verursacht.
(Und natürlich ist das nur paranoid und unbegründet, aber das dachte ich vorher bei vielen anderen Dingen auch...)
Nur mal ein Beispiel: Dieser (nicht nur für mich) überflüssige Binär-Logger journald. Ich brauche keine Logs im Binärformat und bevorzuge Klartext. Letzteres hat einfach den Vorteil, dass man lediglich eine Live-CD braucht, mit der man auf das Dateisystem zugreifen und stinknormale Textdateien lesen kann. Warum wird mir trotzdem der Binärlogger aufgedrängt, der auf meinem RaspberryPi mit Abstand (!) der speicherhungrigste Prozess ist?
Genau darum geht es: Wenn ich irgendeine Komponente von systemd nicht haben will, muss ich sie trotzdem verwenden. In vielen Fällen ist es auch: Paket foo braucht Funktionalität bar von systemd, deshalb muss man dann gleich sein ganzes Init-System austauschen und sie die ganzen ungewollten Extras mitinstallieren, ob man sie jetzt haben will oder nicht. Gut, dies wiederum ist eher ein Vorwurf an die Anwendungsentwickler, die zu unkritisch auf den systemd-Zug aufspringen. Trotzdem ist systemd daran nicht unschuldig, denn es bringt Dinge zusammen, die nicht unbedingt zusammen gehören.
Von cyberpatrol am Di, 17. September 2013 um 14:13 #
Können die Gegner von systemd auch ein paar Fakten liefern, weil bisher kommt immer nur polemisches "Rad neu zu erfinden" "Codebasis auf zu blähen" "Krebs" u.ä. Klingt nach "es ist neu deswegen mag ich es nicht" oder "es ist von Lennart Poettering, deswegen mag ich es nicht".
Können die systemd-Fanboys auch ein paar Fakten liefern, weil bisher kommt immer nur polemisches "sysvinit ist schon 40 Jahre alt und sehr gut getestet und stabil, also ist das völlig veraltet und es muss dringend was neueres her, weil nur neues ist ja gut".
Von systemd-Gegnern hab ich übrigens bisher nur Fakten gehört, die aber die systemd-Fanboys leider hartnäckig ignorieren bzw. einfach nicht wahrhaben wollen.
Das mit dem "das Rad neu erfinden" ist z.B. so einer.
Oder das mit dem "warum man noch einen Systemlogger braucht, der die Logfiles dazu noch nicht lesbar, binär speichert und letztendlich mit seinem Logfile-Leseprogramm nichts anderes macht als ein `less /var/log/everything`" wäre noch ein solcher Fakt, der nie beantwortet bzw. widerlegt wurde. Oder auch die Tatsache, warum man, um lesbare Logfiles zu bekommen, noch einen zweiten, nämlich einen der wirklich ausgereiften Syslogger laufen lassen und somit Systemressourcen verschwenden muss.
Oder das mit den viel zu umständlichen .service-Files. Ach so, stimmt ja, die systemd-Fanboys sind ja zu faul, mal ein wenig zu lernen, wie man Shell-Scripte schreibt, weil die Shell-/Init-Scripte ja viel zu kompliziert sind. Wäre noch ein solcher Fakt.
Dass es keine vernünftigen Konfigurationsdateien gibt wie z.B. die in /etc/conf.d, sondern alles in den .service-Files fest vorgegeben ist und man diese .service-Files, wenn man sie denn editieren will oder muss, extra erst von /lib/systemd/systemd/system/systemd/schlag/mich/tot/irgendwas.service nach /etc/systemd/systemd/system/systemd/schlag/mich/tot/irgendwas.service kopieren muss ist auch noch so ein Fakt.
Und wenn man irgendein schwachsinniges Feature wie dieses Ignorieren der einfachen und aussagekräftigen Devicenamen des Kernels wie z.B. eth0 und das Vergeben von völlig absurden Namen wie es24p3ej oder wie auch immer das heißen mag, deaktivieren will, kann man nicht einfach eine Variable in einer Konfigurationsdatei ändern, sondern muss einen Link nach /dev/null in eben diesem /etc/systemd/system/systemd/schiess/mich/tot setzen. Ist auch ein Fakt, der nie widerlegt werden konnte von diesen systemd-Fanboys.
Ja, udev gehört mittlerweile zu systemd. eudev hat diesen Unsinn, der auch mal ganz nebenbei den Internetzugang und ganze Netzwerke lahmlegen kann, weil kein Script inkl. Firewallscripte mehr funktioniert, leider mit übernommen.
Dann wären wir beim nächsten Fakt. Was sollen diese selten dämlichen, umständlichen und langen Pfade wie /lib/systemd/system/systemd/schlag/mich/tot und das ganze dann nochmal in /etc in Kopie? Davon, dass man dadurch unnötig Festplattenplatz vergeudet, wollen wir gar nicht erst sprechen.
Warum systemd einfach alles, was es schon gibt und was über Jahre ausgereift ist, ersetzen und selbst machen will/muss, konnte oder wollte bisher auch noch kein systemd-Fanboy beantworten.
Und dann waren da noch die ganzen Beleidigungen seitens Lennart Poettering gegen seine bzw. die systemd-Kritiker mitten in der systemd-Dokumentation.
Und dann war da noch das absolut nicht funktionieren PulseAudio. Aber dass PulseAudio nicht mit vernünftigen, (semi-)professionellen Audiokarten umgehen kann, ist ja ein Fehler von ALSA, das übrigens schon seit Jahren perfekt out-of-the-box mit diesen Karten umgehen kann. Der Bugfix, der dann von Lennart Poettering und den anderen PA-Entwicklern kam, war dann, diese (semi-)professionellen Audiokarten, die alle separate, eigenständige Kanäle haben, die beliebig über einen Pachbay gemischt werden können, mit einer ominösen ALSA-Konfigurationsdatei zu einer simplen Stereo-Soundkarte zu verkrüppeln.
Selbstverständlich wurde ich dann von den systemd-Fanboys ausgelacht, als ich mal so vermutete, dass Lennart Poettering demnächst noch den Kernel bzw. die Kernelentwickler für seine eigenen systemd-Bugs verantwortlich macht. Und was war kurze Zeit später? Ich sage nur: "Stop that idiocy!" (Zitat: Linus Torvalds an Kay Sievers gerichtet bzgl. eines Bugs in udev, das zu systemd gehört)
Und jemandem, der noch nicht mal ein halbfertiges Programm liegen lässt bzw. nicht dazu in der Lage ist, erst ein Programm fertig zu schreiben, so dass es auch wirklich funktioniert und zwar auch unter professionellen Bedingungen, und dann (parallel) ein neues Programm bastelt, das zu dem auch noch PID 1 ablösen soll und im Übrigen zumindest unter professionellen Bedingungen auch nicht funktioniert, und nur mit Beleidigungen um sich wirft, soll ich wirklich vertrauen? Wir reden hier wie gesagt u.a. von PID 1.
Brauchst du noch mehr Fakten? Kann ich gerne liefern.
Und ich sehe jetzt schon das ganze unsachliche Getrolle und Genöhle, das jetzt wieder von den ganzen systemd-Fanboys kommt.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 17. Sep 2013 um 14:28.
Von Anonymous Coward am Di, 17. September 2013 um 15:15 #
Oder das mit dem "warum man noch einen Systemlogger braucht, der die Logfiles dazu noch nicht lesbar, binär speichert und letztendlich mit seinem Logfile-Leseprogramm nichts anderes macht als ein `less /var/log/everything`" wäre noch ein solcher Fakt, der nie beantwortet bzw. widerlegt wurde.
Bullshit hoch drei, journalctl kann wesentlich mehr als das. Da all das auch ausführlich dokumentiert ist (man journalctl), spare ich mir hier die Liste.
Oder das mit den viel zu umständlichen .service-Files. Ach so, stimmt ja, die systemd-Fanboys sind ja zu faul, mal ein wenig zu lernen, wie man Shell-Scripte schreibt, weil die Shell-/Init-Scripte ja viel zu kompliziert sind. Wäre noch ein solcher Fakt.
Aua, also .service-Files sind umständlich, aber Shell-Scripte nicht? Offensichtlich hast Du Dir nie die init-Scripte deiner Distribution angeschaut.
Dass es keine vernünftigen Konfigurationsdateien gibt wie z.B. die in /etc/conf.d, sondern alles in den .service-Files fest vorgegeben ist und man diese .service-Files, wenn man sie denn editieren will oder muss, extra erst von /lib/systemd/systemd/system/systemd/schlag/mich/tot/irgendwas.service nach /etc/systemd/systemd/system/systemd/schlag/mich/tot/irgendwas.service kopieren muss ist auch noch so ein Fakt.
Nö, es ist kompletter Schwachsinn. Seit systemd 198 gibt es „drop-in snippets“, mit denen man Einstellungen aus /lib in /etc/ extrem flexibel überschreiben kann (siehe erster Punkt im Announcement). Und was machst Du, wenn Du beim sysvinit-Script Anpassungen brauchst? Wenn Du sie direkt im init-Script vornimmst, werden sie beim nächsten Update des Pakets überschrieben, sysvinit hat für dieses Problem also *gar nichts* anzubieten.
Und wenn man irgendein schwachsinniges Feature wie dieses Ignorieren der einfachen und aussagekräftigen Devicenamen des Kernels wie z.B. eth0 und das Vergeben von völlig absurden Namen wie es24p3ej oder wie auch immer das heißen mag, deaktivieren will, kann man nicht einfach eine Variable in einer Konfigurationsdatei ändern, sondern muss einen Link nach /dev/null in eben diesem /etc/systemd/system/systemd/schiess/mich/tot setzen. Ist auch ein Fakt, der nie widerlegt werden konnte von diesen systemd-Fanboys.
Abgesehen davon, dass die Kernel-Namen wie eth0 weder aussagekräftig (was sagt eth0 bitte aus) noch stabil sind (Tausch der Netzwerkkarte zieht oftmals eine Änderung des Interfacenamens mit sich, wtf?), sehe ich nicht, was daran so schlimm sein soll, einen Symlink zu setzen. Es ist jedenfalls einfacher zu scripten als Änderungen an irgendeiner Konfigurationsdatei.
Dann wären wir beim nächsten Fakt. Was sollen diese selten dämlichen, umständlichen und langen Pfade wie /lib/systemd/system/systemd/schlag/mich/tot und das ganze dann nochmal in /etc in Kopie? Davon, dass man dadurch unnötig Festplattenplatz vergeudet, wollen wir gar nicht erst sprechen.
Dateien in /etc haben Priorität gegenüber denen in /lib. Der Paketmanager legt Konfigurationsdateien in /lib ab, in /etc kann der Administrator sie ggf. überschreiben, und sie bleiben dann erhalten, wenn der Paketmanager eine neue Version des Pakets installiert. Das Verhalten ist also durchdacht und sinnvoll, Du kapierst nur einfach nicht, wovon Du redest.
Warum systemd einfach alles, was es schon gibt und was über Jahre ausgereift ist, ersetzen und selbst machen will/muss, konnte oder wollte bisher auch noch kein systemd-Fanboy beantworten.
Angesichts der oben genannten guten Gründe ist der Grund, dass es Dir niemand erklären konnte, wohl eher Deine Merkbefreiung.
Und dann war da noch das absolut nicht funktionieren PulseAudio. Aber dass PulseAudio nicht mit vernünftigen, (semi-)professionellen Audiokarten umgehen kann, ist ja ein Fehler von ALSA
Wo ist der Thread, wo Poettering das behauptet, und wo ist Dein Beleg, dass seine Aussage falsch ist? Tipp: folgendes ist kein Beleg:
das übrigens schon seit Jahren perfekt out-of-the-box mit diesen Karten umgehen kann.
denn es ist gut möglich, dass PulseAudio Funktionalität im Kernel oder in den Treibern voraussetzt, die andere Applikationen nicht benutzen.
Selbstverständlich wurde ich dann von den systemd-Fanboys ausgelacht, als ich mal so vermutete, dass Lennart Poettering demnächst noch den Kernel bzw. die Kernelentwickler für seine eigenen systemd-Bugs verantwortlich macht. Und was war kurze Zeit später? Ich sage nur: "Stop that idiocy!" (Zitat: Linus Torvalds an Kay Sievers gerichtet bzgl. eines Bugs in udev, das zu systemd gehört)
Also ist jetzt neuerdings Lennart Poettering schuld, wenn Kay Sievers Mist baut? Abgesehen davon ist diese Sache schon ewig geklärt und wird nur noch von systemd-Hassern immer wieder ausgegraben, weil ihnen offenbar keine besseren Argumente einfallen.
und im Übrigen zumindest unter professionellen Bedingungen auch nicht funktioniert
Dummes Getrolle ohne jeden Beleg. Systemd funktioniert besser als jedes andere init-System für Linux, das weiß jeder, der sich mal mit den betreffenden Features auseinandergesetzt hat. Und nein, ich werde jetzt nicht wieder auflisten, was systemd alles besser macht als sysvinit, zum einen, weil die Liste schlicht zu lang wäre, zum anderen, weil jemand, der das immer noch nicht mitbekommen hat, wohl ohnehin unbelehrbar ist.
Brauchst du noch mehr Fakten? Kann ich gerne liefern.
Du solltest überhaupt erstmal einen Fakt liefern, das hast Du nämlich bisher nicht.
Von cyberpatrol am Di, 17. September 2013 um 20:28 #
Bullshit hoch drei, journalctl kann wesentlich mehr als das. Da all das auch ausführlich dokumentiert ist (man journalctl), spare ich mir hier die Liste.
Möglicherweise ist da kürzlich doch mal jemand auf die Idee gekommen, da noch ein paar Features mehr zu programmieren und die auch zu dokumentieren. Kann aber noch nicht lange her sein.
Aua, also .service-Files sind umständlich, aber Shell-Scripte nicht? Offensichtlich hast Du Dir nie die init-Scripte deiner Distribution angeschaut.
Doch habe ich und ich habe auch schon die sogar auch schonmal gepatcht und diesen Patch sogar an die Distributoren weitergeleitet, die die dann sogar in die Distribution aufgenommen haben. Wenn man natürlich gerade erst von Windows zu Linux gewechselt ist, dann kann man mit Scripten schonmal seine Schwierigkeiten haben. Kann man aber lernen. Ist auch gar nicht schwer,.
Wenn Du sie direkt im init-Script vornimmst, werden sie beim nächsten Update des Pakets überschrieben, sysvinit hat für dieses Problem also *gar nichts* anzubieten.
Dann sagst du dem Paketmanager halt, dass er die nicht überschreiben soll. Außerdem musste ich noch nie ein Initscript anpassen. Lediglich einmal ein Feature dazuschreiben, dass dann wie gesagt auch ganz schnell in die Distribution aufgenommen wurde. Denn jedes Init-Script lässt sich problemlos über die entsprechende Konfigurationsdatei (kein Script) in /etc/conf.d konfigurieren.
Abgesehen davon, dass die Kernel-Namen wie eth0 weder aussagekräftig (was sagt eth0 bitte aus) noch stabil sind (Tausch der Netzwerkkarte zieht oftmals eine Änderung des Interfacenamens mit sich, wtf?), sehe ich nicht, was daran so schlimm sein soll, einen Symlink zu setzen. Es ist jedenfalls einfacher zu scripten als Änderungen an irgendeiner Konfigurationsdatei.
eth0 = 1. Ethernetkarte wlan0 = 1. WLAN-Chip
Hätte man aber auch ganz einfach selbst drauf kommen können, wenn man zumindest ein paar Computergrundkenntnisse hätte und ein paar Computergrundbegriffe kennen würde.
Genau diesen Eindruck machen die systemd-Fanboys wie auch die Entwickler, nämlich den, dass sie von professioneller Computernutzung überhaupt keine Ahnung haben und gerade erst von Windows nach Linux gewechselt sind und sich einbilden, dass Linux jetzt genauso wie Windows funktionieren müsste.
Und was bedeutet jetzt bitteschön en23kpe6s oder wie auch immer sich das jetzt nennt?
Im Übrigen kann man die Vergabe der Devicenamen durch den Kernel auch konsistent machen. Denn den Kernelmodulen kann man in der Regel Parameter übergeben, mit denen man auch die Reihenfolge angibt, in der die Module geladen werden. Außerdem gabs in udev schon immer die Möglichkeit, udev-Regeln anzulegen, mit denen man die Namensverteilung konsistent hinbekommt. Und das ging schon, bevor Poettering udev gekapert hat.
Und Symlinks? Irgendwann hast du dein System komplett mit irgendwelchen Symlinks zugemüllt, ohne auch nur einen Funken Überblick mehr zu haben, wo du welche Symlinks gesetzt hast. Eine Konfigurationsdatei kennt und findet man. Mal abgesehen davon, dass so ein Symlink nach /dev/null ganz einfach unter "quick and dirty" oder "workaround" läuft. Ich bevorzuge ein stabiles korrekt arbeitends System.
Dateien in /etc haben Priorität gegenüber denen in /lib. Der Paketmanager legt Konfigurationsdateien in /lib ab, in /etc kann der Administrator sie ggf. überschreiben, und sie bleiben dann erhalten, wenn der Paketmanager eine neue Version des Pakets installiert. Das Verhalten ist also durchdacht und sinnvoll, Du kapierst nur einfach nicht, wovon Du redest.
Und genau diese Kopiererei bedeutet nichts anderes als Verschwendung von Festplattenplatz, weil man nämlich alle angepassten Dateien doppelt irgendwo rumliegen hat. Und jetzt komm mir nur nicht mit 1 oder 2 TB-Platten. Auch die sind irgendwann mal voll. Und wenn dann mal eine dieser Dateien in /lib bei einem Update völlig geändert wird, fragt man sich, warum plötzlich nichts mehr funktioniert, weil man natürlich nicht erfährt, dass sich genau diese Datei geändert hat und man seine Kopie entsrechend anpassen müsste. Einfache Konfigurationsdateien in /etc/conf.d werden dagegen nicht einfach überschrieben. Stattdessen werden die neuen Konfigurationsdateien vom Paketmanager mit einem leicht geänderten Namen auf die Platte geschrieben, so dass man die entweder mit locate oder find oder einem zum Paketmanager gehörenden Tool finden und entsprechend anpassen kann.
Ich glaube jetzt mal, dass eher du nicht weißt, wovon du redest.
Angesichts der oben genannten guten Gründe ist der Grund, dass es Dir niemand erklären konnte, wohl eher Deine Merkbefreiung.
Na, hab ichs nicht gesagt, dass jetzt diese unsachliche Trollerei der systemd-Fanboys kommt? Wie recht ich wieder hatte. Jedesmal dasgleiche. Wenn einem halt die Argumente ausgehen.
Wo ist der Thread, wo Poettering das behauptet, und wo ist Dein Beleg, dass seine Aussage falsch ist? Tipp: folgendes ist kein Beleg:
das übrigens schon seit Jahren perfekt out-of-the-box mit diesen Karten umgehen kann.
denn es ist gut möglich, dass PulseAudio Funktionalität im Kernel oder in den Treibern voraussetzt, die andere Applikationen nicht benutzen.
Doch das ist ein Beleg, wenn ALSA diese Karten seit Jahren out-of-the-box perfekt unterstützt und sogar einen passenden Mixer und einen passenden Patchbay mitbringt und PA nicht, und wenn diese PA-Entwickler sich einbilden, mir erzählen zu müssen, dass ich meine (semi-)professionelle Audiokarte mit einer ALSA-Konfiguration zu einer Stereo-Soundkarte verkrüppeln muss, dann liegt das Problem bei PA und nicht bei ALSA.
Und wenn PA tatsächlich irgendwelche nicht vorhandenen Kernel-Features voraussetzen würde, dann wäre es wohl die Aufgabe der PA-Entwickler diese Kernel-Features mitzuliefern oder einen entsprechenden Featurerequest an die Kernel-Entwickler zu schicken. Warum das wohl nicht gemacht wurde?
Du kannst es aber auch gerne selbst ausprobieren. Kauf dir doch spasseshalber mal eine M-Audio Audiophile 24/96 oder eine RME Hammerfall und versuch mal, PA damit laufen zu lassen. Kannst mir dann ja mal bescheid sagen. Ich wünsch dir schonmal viel Spaß.
Du kannst aber auch andere fragen, die sich damit auskennen, also nicht die PA-Entwickler, sondern Audio-Profis.
Wenn man keine Ahnung hat, sollte man halt lieber mal still sein.
Systemd funktioniert besser als jedes andere init-System für Linux, das weiß jeder, der sich mal mit den betreffenden Features auseinandergesetzt hat.
*rofl*
Nur komisch, dass ich davon nichts bemerkt habe und ich habe mich mit den betreffenden Features auseinandergesetzt.
Im Übrigen habe ich systemd mal installiert, als es angeblich schon super stabil und schnell gewesen sein soll und jedem User dieser Distribution aufgezwungen wurde. Ich habe es sofort wieder runtergeschmissen, weil gar nichts funktioniert hat und schon gar nicht so, wie ich das wollte. Und an die Unix-Standards und -Philosophie hält sich das Teil ohnehin nicht.
Du solltest überhaupt erstmal einen Fakt liefern, das hast Du nämlich bisher nicht.
*rofl*
Und ich hatte schon wieder recht. Diese systemd-Fanboys ignorieren hartnäckig jeden einzelnen Fakt, bringen selbst nur Polemik und Beleidigungen gegenüber den systemd-Kritikern und behaupten dann, man hätte ja keine technischen Fakten vorgelegt.
Du bist wieder ein Paradebeispiel dafür.
So ignorant und arrogant wie diese systemd-Entwickler und -Fanboys kann man eigentlich gar nicht sein.
Von Anonymous Coward am Mi, 18. September 2013 um 14:13 #
Möglicherweise ist da kürzlich doch mal jemand auf die Idee gekommen, da noch ein paar Features mehr zu programmieren und die auch zu dokumentieren.
Die systemd-Dokumentation ist praktisch seit Beginn des Projekts vollständiger als alles, was jemals aus der sysvinit-Ecke kam, also spar Dir das Getrolle.
Doch habe ich und ich habe auch schon die sogar auch schonmal gepatcht und diesen Patch sogar an die Distributoren weitergeleitet, die die dann sogar in die Distribution aufgenommen haben. Wenn man natürlich gerade erst von Windows zu Linux gewechselt ist, dann kann man mit Scripten schonmal seine Schwierigkeiten haben. Kann man aber lernen. Ist auch gar nicht schwer,.
Ich finde Shell-Scripting furchtbar *weil* ich besser als die meisten weiß, was das für ein Frickelmist ist. Und dem stimmt auch jeder zu, der weiß, wovon er redet. Die Systemd-unit-Dateien sind wesentlich einfacher und deklarativer.
Dann sagst du dem Paketmanager halt, dass er die nicht überschreiben soll.
Selbst wenn das ginge (mir ist keine Möglichkeit bekannt, bspw. dpkg zu vermitteln, dass bestimmte Dateien nicht überschrieben werden sollen, ohne das Update des betreffenden Pakets ganz zu unterbinden), wäre es der Systemd-Lösung unterlegen. Angenommen, Du willst, dass bei irgendeinem Dienst foobar z. B. eine Environment-Variable gesetzt wird, während für alles andere die Konfigurationsparameter des Pakets verwendet werden. Du packst ein entsprechendes Drop-in-Snippet nach /etc/systemd/system/foobar.service.d und alles ist gut. Wenn jetzt ein Update des foobar-Pakets Änderungen an /lib/systemd/system/foobar.service vornimmt, werden diese automatisch übernommen. Vor dem Hintergrund, dass Änderungen an solchen Konfigurationsdateien sicherheitskritisch sein können, ist das ein Killerfeature, was mit init-Scripten schlicht nicht möglich ist, da sie nicht deklarativ sind.
eth0 = 1. Ethernetkarte wlan0 = 1. WLAN-Chip
Jaja, soweit die Theorie. Bis man dann ein paar mal die Netzwerkkarte tauscht und die Ethernetkarte dann auf einmal eth4 heißt, wie es auf einem meiner Systeme jahrelang der Fall war. Offensichtlich hast Du keine Ahnung, wovon Du redest.
Und was bedeutet jetzt bitteschön en23kpe6s oder wie auch immer sich das jetzt nennt?
Das ist ausführlich in der Dokumentation erklärt, die zu lesen Du offenbar nicht in der Lage bist. Und es wird auch ausführlich erklärt, warum die Sachen jetzt so gemacht werden, wie sie gemacht werden. Zudem sind Namen wie en23kpe6s die absolute Ausnahme. Viel typischer sind Namen wie usb0 (Handy per USB-Tethering), em1 (gemäß Chassis-Label) oder p10p1 (PCI-Slot 10, Port 1 -- eine Bezeichnung, die im Gegensatz zu Kernel-Namen immer die gleiche bleibt, auch wenn man z. B. die Netzwerkkarte tauscht oder das Timing bei der Hardware-Discovery ein anderes ist). Allesamt sinnvoller und aussagekräftiger als "eth0" & Co..
Im Übrigen kann man die Vergabe der Devicenamen durch den Kernel auch konsistent machen. Denn den Kernelmodulen kann man in der Regel Parameter übergeben, mit denen man auch die Reihenfolge angibt, in der die Module geladen werden.
Ach, und wenn mehrere Netzwerkkarten vom gleichen Treiber bedient werden, was dann? Wieder mal ein Beweis, dass Du keinen blassen Schimmer hast, wovon Du sprichst.
Und Symlinks? Irgendwann hast du dein System komplett mit irgendwelchen Symlinks zugemüllt, ohne auch nur einen Funken Überblick mehr zu haben, wo du welche Symlinks gesetzt hast. Eine Konfigurationsdatei kennt und findet man.
Eine Liste aller Symlinks kann man sich trivial zusammenbauen (z. B. mit `find / -type l`), wie soll da bitte die Übersicht verloren gehen?
Mal abgesehen davon, dass so ein Symlink nach /dev/null ganz einfach unter "quick and dirty" oder "workaround" läuft.
Ich frage wohl besser nicht nach einer Begründung für diesen Bullshit und weise einfach mal darauf hin, dass Symlinks zu setzen und zu löschen immer noch wesentlich einfacher scriptbar ist als Änderungen an einer Konfigurationsdatei.
Und genau diese Kopiererei bedeutet nichts anderes als Verschwendung von Festplattenplatz, weil man nämlich alle angepassten Dateien doppelt irgendwo rumliegen hat. Und jetzt komm mir nur nicht mit 1 oder 2 TB-Platten. Auch die sind irgendwann mal voll. Und wenn dann mal eine dieser Dateien in /lib bei einem Update völlig geändert wird, fragt man sich, warum plötzlich nichts mehr funktioniert, weil man natürlich nicht erfährt, dass sich genau diese Datei geändert hat und man seine Kopie entsrechend anpassen müsste
**ROFLMAO** Genau, weil das ja auch das größte Problem ist bei Konfigurationsdateien, die selten größer als 1kb werden. Da wird doch tatsächlich schon bei einer Milliarde Konfigurationsdateien der Festplattenplatz knapp! Mal abgesehen davon, dass Init-Scripte gerne 5-10mal länger als die entsprechenden sysvinit-Scripte sind, und davon, dass Du das (simple!) Konzept der Drop-In-Snippets offenbar immer noch nicht kapiert hast, denn damit sind deine dämlichen Pseudo-Argumente erst recht hinfällig.
Doch das ist ein Beleg, wenn ALSA diese Karten seit Jahren out-of-the-box perfekt unterstützt und sogar einen passenden Mixer und einen passenden Patchbay mitbringt und PA nicht, und wenn diese PA-Entwickler sich einbilden, mir erzählen zu müssen, dass ich meine (semi-)professionelle Audiokarte mit einer ALSA-Konfiguration zu einer Stereo-Soundkarte verkrüppeln muss, dann liegt das Problem bei PA und nicht bei ALSA.
Abgesehen davon, dass Du immer noch nicht gezeigt hast, wo genau Poettering nun unbegründet anderen die Schuld in die Schuhe schiebt, ist PulseAudio schon immer eine Lösung für Consumer-Audio gewesen, was auch Poettering immer so kommuniziert hat. Schon allein deswegen ist Deine Kritik albern.
Und wenn PA tatsächlich irgendwelche nicht vorhandenen Kernel-Features voraussetzen würde, dann wäre es wohl die Aufgabe der PA-Entwickler diese Kernel-Features mitzuliefern oder einen entsprechenden Featurerequest an die Kernel-Entwickler zu schicken. Warum das wohl nicht gemacht wurde?
Unter anderem weil der Kernel kein stabiles ABI bietet, gegen das man entwickeln könnte. Und weil es auch nicht die Aufgabe der PA-Entwickler ist, Bugs im Kernel zu fixen, besonders wenn diese Bugs Hardware betreffen, die die betreffenden Entwickler nicht unbedingt besitzen.
Nur komisch, dass ich davon nichts bemerkt habe und ich habe mich mit den betreffenden Features auseinandergesetzt.
Ach. Also welches andere Init-System bietet Prozessmanagement mit Cgroups, Ressourcenlimits, Syscall-Filtering, SELinux-Unterstützung, Socket based activation, device activation, bus-based activation und noch vieles mehr? Und jetzt fragst Du noch, warum Leute Dich für merkbefreit halten?
Im Übrigen habe ich systemd mal installiert, als es angeblich schon super stabil und schnell gewesen sein soll und jedem User dieser Distribution aufgezwungen wurde. Ich habe es sofort wieder runtergeschmissen, weil gar nichts funktioniert hat und schon gar nicht so, wie ich das wollte.
Ich hatte auch Probleme, als ich systemd das erste Mal eingesetzt habe. Im Gegensatz zu Dir habe ich diese aber sorgfältig untersucht und letztendlich hat sich herausgestellt, dass das Problem nicht systemd, sondern kaputte init-Scripte waren (zyklische Abhängigkeiten in den LSB-Headern, die Frickel-sysvinit gekonnt ignoriert hat -- prost Mahlzeit).
Und an die Unix-Standards und -Philosophie hält sich das Teil ohnehin nicht.
Abgesehen davon, dass man darüber geteilter Meinung sein kann (eine Begründung hast Du ja nicht geliefert), ist es auch vollkommen unerheblich. Software wird nach Stabilität, Performance, Funktionalität usw. bewertet, und nicht danach, ob sie irgendeinem dogmatischen Regelwerk folgt, das irgendjemand als „Unix-Philosphie“ bezeichnet, und das ich für die heutige Zeit als unbrauchbar ansehe. Und damit bin ich nicht allein. Nettes Zitat von Unix-Urgestein Rob Pike: „Not only is UNIX dead, it's starting to smell really bad“.
Ganz ehrlich, ich würde Dir empfehlen, von weiteren Antworten abzusehen. Es ist ohnehin schon peinlich genug für Dich.
Von cyberpatrol am Mi, 18. September 2013 um 15:37 #
Ganz ehrlich, ich würde Dir empfehlen, von weiteren Antworten abzusehen. Es ist ohnehin schon peinlich genug für Dich.
Ich werde tatsächlich von weiteren Antworten absehen, weil du so einen unglaublichen, unvorstellbaren Schwachsinn von dir gibst, dass es nicht mehr auszuhalten ist. Mach dir aber nichts draus. Ist typisch für systemd-Fanboys.
Und darauf zu antworten ist mir wirklich zu anstrengend. Und dir erstmal überhaupt die grundlegendsten Computer- und Linuxkenntnisse beizubringen, dafür ist hier nicht der geeignete Rahmen.
Ich schlage dir vor, du machst erstmal die Schule fertig, machst dann mal eine Ausbildung oder ein Studium im Bereicht der Informatik und lässt dir vor allem erstmal ein paar Unix-/Linuxgrundlagen beibringen. Dann reden wir irgendwann mal weiter.
Und vor allem dann wieder diese Beleidigungen. Auch typisch für systemd-Fanboys. Keine vernünftigen, haltbaren Argumente liefern, aber mit Beleidigungen um sich werfen.
Von Klaus Meier am Mo, 16. September 2013 um 21:51 #
Ok, es ist unter Gentoo noch nicht perfekt und es funktioniert noch nicht alles, aber bislang gefällt es mir sehr gut. Na und wegen Gnome wird da jetzt auch verstärkt dran gearbeitet.
Habe mich gerade etwas mit Journald beschäftigt und es ist sehr schön. Kann aber auch daran liegen, dass ich mir syslog-ng noch nie so genau angesehen habe. Es ist halt alles etwas anders, wenn man aber offen herangeht, aber auf keinen Fall schlechter. Da scheint es bei einigen wohl eine Poettering Phobie zu geben. Pulseaudio meiden ja auch einige wie der Teufel das Weihwasser. So weit, so gut.
Das man jetzt aber dank Gnome 3.8 dazu gezwungen wird, ist etwas, was nicht sein darf. Eventuell wird das Gnome noch mehr schaden.
Von Unerkannt am Mo, 16. September 2013 um 22:51 #
Pulseaudio meiden ja auch einige wie der Teufel das Weihwasser.
Aus gutem Grund. Warum sollte man einen zusätzliche und unnütze Schicht zwischen Software und Hardware schalten? Ich würde es vielleicht verwenden wenn ich die Funktionalität die damit kommt brauchen würde. Aber ich brauche sie einfach nicht.
Also ich finde es unnötig, was systemd und co da machen ist nichts anderes das Rad neu zu erfinden und die Codebasis auf zu blähen und ein System unnötig zu verkomplizieren. Ein mit Grund für mich von Debian und co zu BSD (OpenBSD) zu wechseln.
Debian setzt systemd (noch) nicht ein, es ist lediglich im Repository. Ob Debian überhaupt systemd einsetzen wird oder doch lieber upstart nimmt oder gar sysv-init treu bleibt, ist lange noch nicht entschieden.
Debian wird sich dem nicht wirklich widersetzen können, Gnome z.B. hat komplett auf Systemd umgestellt. Letztendlich verfügt Debian nicht über das Know-How und die Entwicklerressourcen, um hier langfristig sein eigenes Süppchen kochen zu können.
Das Problem sehe ich auch darin, wenn SystemD immer tiefer in Gnome integriert wird. Es frisst sich da wie Krebs hinein und kann irgendwann nicht mehr entfernt werden. Irgendwann werden es wohl alle einsetzen müssen, egal ob sie es brauchen oder nicht...
das ist das Problem hinter systemd, mittlerweile setzen fast alle darauf. durch irgendwelche Abhängigkeiten ist man früher oder später gezwungen es zu nutzen.
diese umgreifende Featuritis und Automatisierung ist mittlerweile nervig. Ging es früher darum, dass die Tools möglichst gut aufeinander abgestimmt sind, wird jetzt alles in eins gepackt. Heute bekommt man schon komische Blicke, wenn man das bewährte LVM + FS einem Featuremonster wie BtrFs oder zfs vorzieht.
Soweit ich das verstanden habe ist das, zumindest derzeit, noch kein Problem, es werden lediglich einige D-Bus Schnittstellen benutzt, die z.B. von systemd bereit gestellt werden.
Ab Gnome 3.8 funktioniert ohne Systemd z.B. das Powermanagement nicht mehr, genausowenig wie GDM und Multi Seat-Unterstützung.
In diesem Sinne sollte man Systemd ab Gnome 3.8 doch als "Zwangsabhängigkeit" auffassen.
Ich kenne mich da zu wenig aus, aber ich schätze es ist vielleicht so gemeint, dass es kein harte Abhängigkeit ist.
Aber wahrscheinlich ist es eine de-facto Abhängigkeit solange kein anderer Systemdienst die jeweiligen D-Bus Schnittstellen hat.
Wie es aussieht braucht man SystemD damit Gnome 3.8 richtig läuft. Es geht wohl über ein paar optionale D-Bus-Schnittstellen hinaus. Bei Ubuntu und Gentoo hat man es wohl versucht, Gnome ohne SystemD zu bekommen und ist gescheitert. Gnome und SystemD greifen hier direkt die Wahlfreiheit der Nutzer an. Das ist eine Schweinerei.
http://my.opera.com/pacho/blog/2013/07/24/gnome-3-8-requiring-systemd-on-gentoo
Wie es aussieht braucht man SystemD damit Gnome 3.8 richtig läuft. Es geht wohl über ein paar optionale D-Bus-Schnittstellen hinaus. Bei Ubuntu und Gentoo hat man es wohl versucht, Gnome ohne SystemD zu bekommen und ist gescheitert.
Ubuntu wird nur einen kleinen Teil von systemd verwenden ("logind"). Der ist tatsächlich Teil von systemd, erzwingt aber nicht den Wechsel des init-Prozesses.
Das ist aber auch nur bis systemd-204 möglich. Alle neueren Versionen haben logind direkt in systemd integriert (AFAIK kein eigens tool mehr). Somit kann ubuntu nicht auf eine neuere Version von systemd umstellen, was aus sicherheitstechnischer Sicht recht problematisch werden kann.
Erinnert mich sehr das was Microsoft immer vorgeworfen wird: "Embrace, extend and extinguish".
Hast du auch überprüft ob sich logind ohne systemd betreiben lässt?
Ah, kann sein. Wie gesagt habe ich da keinen direkten Einblick, das war meine Interpretation von entsprechende Kommentaren von GNOME Entwicklern in diversen Kommentarbereichen.
"Gnome z.B. hat komplett auf Systemd umgestellt"
Wie kommt es dass gnome z.B. in Ubuntu ohne systemd auskommt?
Komm den Leuten doch nicht mit Fakten.
Gilt das auch für das besagte Gnome 3.8?
Ich vermute einmal, dass die oben erwähnten Gnome 3.8-"Features" (Powermanagement, GDM, Multi Seat) unter einem Ubuntu mit Gnome 3.8 ohne Systemd nicht funktionieren. "Systemd-services" steht übrigens in den Recommends und wird demzufolge anscheinend automatisch mitinstalliert. Gnome 3 befindet sich mittlerweile sowieso in Ubuntu Universe, von daher wird das Shuttleworth und Co. hochgradig egal sein.
Ubuntu nutzt die entsprechenden Versionen noch nicht.
Zudem sind es keine Must-Have Features, aber doch einige die stören.
ubuntu hat entweder noch nicht gnome-3.8 Pakete verfügbar, oder (wahrscheinlichere These) sie bleiben bei systemd-204, weil man dort logind ohne den Rest von systemd verwenden kann. Das geht allerdings seit systemd-205 nicht mehr (siehe mein Kommentar weiter oben).
Das Problem für Debian ist, dass sie mehrere Kernel unterstützen. Neben Linux noch mindestens BSD, ich glaube sogar Hurd.
Es gibt ja durchaus noch Distributionen die ohne systemd kommen. Ich kann dich verstehen. Man ist trotzdem noch nicht gezwungen das Linux Boot ganz zu verlassen.
Können die Gegner von systemd auch ein paar Fakten liefern, weil bisher kommt immer nur polemisches "Rad neu zu erfinden" "Codebasis auf zu blähen" "Krebs" u.ä. Klingt nach "es ist neu deswegen mag ich es nicht" oder "es ist von Lennart Poettering, deswegen mag ich es nicht".
The Biggest Myths
http://0pointer.de/blog/projects/the-biggest-myths.html
* Myth: systemd is monolithic
* Myth: systemd is not modular
* Myth: systemd was created as result of the NIH syndrome
* Myth: systemd is bloated
* Myth: systemd being Linux-only is not nice to the BSDs
* etc.
Ich denke wenn Morgen deine Lieblingsdistribution auf systemd umgestellt wird, würdest du als Nutzer überhaupt nichts merken (bis auf vllt. einen schnelleren Bootvorgang).
Ich finde dass diese Datei für systemd wesentlich besser ist als ein 100 Zeilen langes sys-v Script (ist mein erstes, eigenes Script dass ich nach 10 Minuten lesen der systemd Dokumentation erstellt habe):
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Sep 2013 um 13:00.Meine Lieblingsdistribution wird nicht auf systemd wechseln...
Unabhängig davon ist es auf jeden Fall schlecht, dass systemd eine Abhängigkeit von Gnome ist. Das bedeutet, dass jede Distribution, die Gnome verwenden will, auch systemd nehmen muss. Das ist nicht in Ordnung!
Moment von welchen Features redest du?
Ich vermute das Meiste ging bereits vor Systemd diese Aufgaben übernommen hat.
Beispielsweise vernünftige Multiseat-Unterstützung.
Wird bestimmt lustig, wenn systemd versucht, meine sshfs-Mounts an unterschiedlichen Ports mit unterschiedlichen Usern per Keyfile und mit ’ne Handvoll spezieller Optionen zu mounten.
LABEL=home, LABEL=root und LABEL=swap bekommt jedes halbwegs ausgewachsene Shellscript hin, dass systemd das kann, ist klar, aber ansonsten?
systemd hat für mich nur Vorteile, aber ich sehe auch – annders als Lennart – die Realität.
Niemand hat die Absicht deine Mountoptionen zu erraten.
Ich mag systemd und setze es selbst ein, aber, es wird zu großen Teilen von Red Hat entwickelt, einer US Firma und ist (neben dem Linux Kernel selbst) vermutlich die beste Möglichkeit Schlupflöcher in das System einzubauen. Das ist momentan der wesentliche Grund, der mir bei systemd Bauchschmerzen verursacht.
(Und natürlich ist das nur paranoid und unbegründet, aber das dachte ich vorher bei vielen anderen Dingen auch...)
Da mache ich mir viel größere Sorgen z.B. um meinen Mips-Linux-Router, so von wegen "Zufallszahlengenerator" und zugehörige Entropieprobleme.
Das ist flächendeckend der beste Weg, um über schwache kryptographische Schlüssel doch noch zum "Ziel" zu gelangen.
Siehe z.B.:
http://www.heise.de/security/meldung/MIPS-Router-mit-Entropieproblemen-1953097.html
Natürlich handelt es sich hierbei IMO um einen Fehler, nur zeigt das obige Beispiel gut, wo überall schwerwiegende Schwachstellen lauern können.
Ein gutgemeinter Patch und ... /&$%/&$!!!. Debian lässt grüßen.
Nur mal ein Beispiel: Dieser (nicht nur für mich) überflüssige Binär-Logger journald. Ich brauche keine Logs im Binärformat und bevorzuge Klartext. Letzteres hat einfach den Vorteil, dass man lediglich eine Live-CD braucht, mit der man auf das Dateisystem zugreifen und stinknormale Textdateien lesen kann. Warum wird mir trotzdem der Binärlogger aufgedrängt, der auf meinem RaspberryPi mit Abstand (!) der speicherhungrigste Prozess ist?
Genau darum geht es: Wenn ich irgendeine Komponente von systemd nicht haben will, muss ich sie trotzdem verwenden. In vielen Fällen ist es auch: Paket foo braucht Funktionalität bar von systemd, deshalb muss man dann gleich sein ganzes Init-System austauschen und sie die ganzen ungewollten Extras mitinstallieren, ob man sie jetzt haben will oder nicht. Gut, dies wiederum ist eher ein Vorwurf an die Anwendungsentwickler, die zu unkritisch auf den systemd-Zug aufspringen. Trotzdem ist systemd daran nicht unschuldig, denn es bringt Dinge zusammen, die nicht unbedingt zusammen gehören.
Von systemd-Gegnern hab ich übrigens bisher nur Fakten gehört, die aber die systemd-Fanboys leider hartnäckig ignorieren bzw. einfach nicht wahrhaben wollen.
Das mit dem "das Rad neu erfinden" ist z.B. so einer.
Oder das mit dem "warum man noch einen Systemlogger braucht, der die Logfiles dazu noch nicht lesbar, binär speichert und letztendlich mit seinem Logfile-Leseprogramm nichts anderes macht als ein `less /var/log/everything`" wäre noch ein solcher Fakt, der nie beantwortet bzw. widerlegt wurde. Oder auch die Tatsache, warum man, um lesbare Logfiles zu bekommen, noch einen zweiten, nämlich einen der wirklich ausgereiften Syslogger laufen lassen und somit Systemressourcen verschwenden muss.
Oder das mit den viel zu umständlichen .service-Files. Ach so, stimmt ja, die systemd-Fanboys sind ja zu faul, mal ein wenig zu lernen, wie man Shell-Scripte schreibt, weil die Shell-/Init-Scripte ja viel zu kompliziert sind. Wäre noch ein solcher Fakt.
Dass es keine vernünftigen Konfigurationsdateien gibt wie z.B. die in /etc/conf.d, sondern alles in den .service-Files fest vorgegeben ist und man diese .service-Files, wenn man sie denn editieren will oder muss, extra erst von /lib/systemd/systemd/system/systemd/schlag/mich/tot/irgendwas.service nach /etc/systemd/systemd/system/systemd/schlag/mich/tot/irgendwas.service kopieren muss ist auch noch so ein Fakt.
Und wenn man irgendein schwachsinniges Feature wie dieses Ignorieren der einfachen und aussagekräftigen Devicenamen des Kernels wie z.B. eth0 und das Vergeben von völlig absurden Namen wie es24p3ej oder wie auch immer das heißen mag, deaktivieren will, kann man nicht einfach eine Variable in einer Konfigurationsdatei ändern, sondern muss einen Link nach /dev/null in eben diesem /etc/systemd/system/systemd/schiess/mich/tot setzen. Ist auch ein Fakt, der nie widerlegt werden konnte von diesen systemd-Fanboys.
Ja, udev gehört mittlerweile zu systemd. eudev hat diesen Unsinn, der auch mal ganz nebenbei den Internetzugang und ganze Netzwerke lahmlegen kann, weil kein Script inkl. Firewallscripte mehr funktioniert, leider mit übernommen.
Dann wären wir beim nächsten Fakt. Was sollen diese selten dämlichen, umständlichen und langen Pfade wie /lib/systemd/system/systemd/schlag/mich/tot und das ganze dann nochmal in /etc in Kopie? Davon, dass man dadurch unnötig Festplattenplatz vergeudet, wollen wir gar nicht erst sprechen.
Warum systemd einfach alles, was es schon gibt und was über Jahre ausgereift ist, ersetzen und selbst machen will/muss, konnte oder wollte bisher auch noch kein systemd-Fanboy beantworten.
Und dann waren da noch die ganzen Beleidigungen seitens Lennart Poettering gegen seine bzw. die systemd-Kritiker mitten in der systemd-Dokumentation.
Und dann war da noch das absolut nicht funktionieren PulseAudio. Aber dass PulseAudio nicht mit vernünftigen, (semi-)professionellen Audiokarten umgehen kann, ist ja ein Fehler von ALSA, das übrigens schon seit Jahren perfekt out-of-the-box mit diesen Karten umgehen kann. Der Bugfix, der dann von Lennart Poettering und den anderen PA-Entwicklern kam, war dann, diese (semi-)professionellen Audiokarten, die alle separate, eigenständige Kanäle haben, die beliebig über einen Pachbay gemischt werden können, mit einer ominösen ALSA-Konfigurationsdatei zu einer simplen Stereo-Soundkarte zu verkrüppeln.
Selbstverständlich wurde ich dann von den systemd-Fanboys ausgelacht, als ich mal so vermutete, dass Lennart Poettering demnächst noch den Kernel bzw. die Kernelentwickler für seine eigenen systemd-Bugs verantwortlich macht. Und was war kurze Zeit später? Ich sage nur: "Stop that idiocy!" (Zitat: Linus Torvalds an Kay Sievers gerichtet bzgl. eines Bugs in udev, das zu systemd gehört)
Und jemandem, der noch nicht mal ein halbfertiges Programm liegen lässt bzw. nicht dazu in der Lage ist, erst ein Programm fertig zu schreiben, so dass es auch wirklich funktioniert und zwar auch unter professionellen Bedingungen, und dann (parallel) ein neues Programm bastelt, das zu dem auch noch PID 1 ablösen soll und im Übrigen zumindest unter professionellen Bedingungen auch nicht funktioniert, und nur mit Beleidigungen um sich wirft, soll ich wirklich vertrauen? Wir reden hier wie gesagt u.a. von PID 1.
Brauchst du noch mehr Fakten? Kann ich gerne liefern.
Und ich sehe jetzt schon das ganze unsachliche Getrolle und Genöhle, das jetzt wieder von den ganzen systemd-Fanboys kommt.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 17. Sep 2013 um 14:28.wlan0 = 1. WLAN-Chip
Hätte man aber auch ganz einfach selbst drauf kommen können, wenn man zumindest ein paar Computergrundkenntnisse hätte und ein paar Computergrundbegriffe kennen würde.
Genau diesen Eindruck machen die systemd-Fanboys wie auch die Entwickler, nämlich den, dass sie von professioneller Computernutzung überhaupt keine Ahnung haben und gerade erst von Windows nach Linux gewechselt sind und sich einbilden, dass Linux jetzt genauso wie Windows funktionieren müsste.
Und was bedeutet jetzt bitteschön en23kpe6s oder wie auch immer sich das jetzt nennt?
Im Übrigen kann man die Vergabe der Devicenamen durch den Kernel auch konsistent machen. Denn den Kernelmodulen kann man in der Regel Parameter übergeben, mit denen man auch die Reihenfolge angibt, in der die Module geladen werden. Außerdem gabs in udev schon immer die Möglichkeit, udev-Regeln anzulegen, mit denen man die Namensverteilung konsistent hinbekommt. Und das ging schon, bevor Poettering udev gekapert hat.
Und Symlinks? Irgendwann hast du dein System komplett mit irgendwelchen Symlinks zugemüllt, ohne auch nur einen Funken Überblick mehr zu haben, wo du welche Symlinks gesetzt hast. Eine Konfigurationsdatei kennt und findet man. Mal abgesehen davon, dass so ein Symlink nach /dev/null ganz einfach unter "quick and dirty" oder "workaround" läuft. Ich bevorzuge ein stabiles korrekt arbeitends System.
Und genau diese Kopiererei bedeutet nichts anderes als Verschwendung von Festplattenplatz, weil man nämlich alle angepassten Dateien doppelt irgendwo rumliegen hat. Und jetzt komm mir nur nicht mit 1 oder 2 TB-Platten. Auch die sind irgendwann mal voll. Und wenn dann mal eine dieser Dateien in /lib bei einem Update völlig geändert wird, fragt man sich, warum plötzlich nichts mehr funktioniert, weil man natürlich nicht erfährt, dass sich genau diese Datei geändert hat und man seine Kopie entsrechend anpassen müsste. Einfache Konfigurationsdateien in /etc/conf.d werden dagegen nicht einfach überschrieben. Stattdessen werden die neuen Konfigurationsdateien vom Paketmanager mit einem leicht geänderten Namen auf die Platte geschrieben, so dass man die entweder mit locate oder find oder einem zum Paketmanager gehörenden Tool finden und entsprechend anpassen kann.Ich glaube jetzt mal, dass eher du nicht weißt, wovon du redest.
Na, hab ichs nicht gesagt, dass jetzt diese unsachliche Trollerei der systemd-Fanboys kommt? Wie recht ich wieder hatte. Jedesmal dasgleiche. Wenn einem halt die Argumente ausgehen.Doch das ist ein Beleg, wenn ALSA diese Karten seit Jahren out-of-the-box perfekt unterstützt und sogar einen passenden Mixer und einen passenden Patchbay mitbringt und PA nicht, und wenn diese PA-Entwickler sich einbilden, mir erzählen zu müssen, dass ich meine (semi-)professionelle Audiokarte mit einer ALSA-Konfiguration zu einer Stereo-Soundkarte verkrüppeln muss, dann liegt das Problem bei PA und nicht bei ALSA.Und wenn PA tatsächlich irgendwelche nicht vorhandenen Kernel-Features voraussetzen würde, dann wäre es wohl die Aufgabe der PA-Entwickler diese Kernel-Features mitzuliefern oder einen entsprechenden Featurerequest an die Kernel-Entwickler zu schicken. Warum das wohl nicht gemacht wurde?
Du kannst es aber auch gerne selbst ausprobieren. Kauf dir doch spasseshalber mal eine M-Audio Audiophile 24/96 oder eine RME Hammerfall und versuch mal, PA damit laufen zu lassen. Kannst mir dann ja mal bescheid sagen. Ich wünsch dir schonmal viel Spaß.
Du kannst aber auch andere fragen, die sich damit auskennen, also nicht die PA-Entwickler, sondern Audio-Profis.
Wenn man keine Ahnung hat, sollte man halt lieber mal still sein.
*rofl*Nur komisch, dass ich davon nichts bemerkt habe und ich habe mich mit den betreffenden Features auseinandergesetzt.
Im Übrigen habe ich systemd mal installiert, als es angeblich schon super stabil und schnell gewesen sein soll und jedem User dieser Distribution aufgezwungen wurde. Ich habe es sofort wieder runtergeschmissen, weil gar nichts funktioniert hat und schon gar nicht so, wie ich das wollte. Und an die Unix-Standards und -Philosophie hält sich das Teil ohnehin nicht.
*rofl*Und ich hatte schon wieder recht. Diese systemd-Fanboys ignorieren hartnäckig jeden einzelnen Fakt, bringen selbst nur Polemik und Beleidigungen gegenüber den systemd-Kritikern und behaupten dann, man hätte ja keine technischen Fakten vorgelegt.
Du bist wieder ein Paradebeispiel dafür.
So ignorant und arrogant wie diese systemd-Entwickler und -Fanboys kann man eigentlich gar nicht sein.
Ganz ehrlich, ich würde Dir empfehlen, von weiteren Antworten abzusehen. Es ist ohnehin schon peinlich genug für Dich.
Und darauf zu antworten ist mir wirklich zu anstrengend. Und dir erstmal überhaupt die grundlegendsten Computer- und Linuxkenntnisse beizubringen, dafür ist hier nicht der geeignete Rahmen.
Ich schlage dir vor, du machst erstmal die Schule fertig, machst dann mal eine Ausbildung oder ein Studium im Bereicht der Informatik und lässt dir vor allem erstmal ein paar Unix-/Linuxgrundlagen beibringen. Dann reden wir irgendwann mal weiter.
Und vor allem dann wieder diese Beleidigungen. Auch typisch für systemd-Fanboys. Keine vernünftigen, haltbaren Argumente liefern, aber mit Beleidigungen um sich werfen.
Ok, es ist unter Gentoo noch nicht perfekt und es funktioniert noch nicht alles, aber bislang gefällt es mir sehr gut. Na und wegen Gnome wird da jetzt auch verstärkt dran gearbeitet.
Habe mich gerade etwas mit Journald beschäftigt und es ist sehr schön. Kann aber auch daran liegen, dass ich mir syslog-ng noch nie so genau angesehen habe. Es ist halt alles etwas anders, wenn man aber offen herangeht, aber auf keinen Fall schlechter. Da scheint es bei einigen wohl eine Poettering Phobie zu geben. Pulseaudio meiden ja auch einige wie der Teufel das Weihwasser. So weit, so gut.
Das man jetzt aber dank Gnome 3.8 dazu gezwungen wird, ist etwas, was nicht sein darf. Eventuell wird das Gnome noch mehr schaden.
Alternative wäre, auf Gnome ganz zu verzichten und z.B. nach Xfce zu wechseln.
Wie gut, dass es unter Gentoo noch OpenRC und eudev gibt. Und das soll sich, wie ich gelesen habe, so schnell auch nicht ändern.