Boycott Systemd

Status
Für weitere Antworten geschlossen.
Es hat schon seine Gründe warum andere Distros solange brauchen um aktuelle Pakete nachzuliefern. Manche testen sogar, bei ArchLinux wird in der Regel nix getestet, weshalb ich mich ja frage wie man das produktiv einsetzen kann. Ich empfinde die Idee alle 6 Monate mal eine neue Version mittlerweile ganz entspannend. Besser wäre es natürlich nur einzelne Programme aktualisieren zu können, statt den gesamten, Verzeihung Rotz, von neuem. Ich hatte nicht das Gefühl das alle Server von der Geschwindigkeit und der akutellsten Pakete im Sync waren.
 
darktrym schrieb:
Es hat schon seine Gründe warum andere Distros solange brauchen um aktuelle Pakete nachzuliefern. Manche testen sogar, bei ArchLinux wird in der Regel nix getestet, weshalb ich mich ja frage wie man das produktiv einsetzen kann.
Zum Vergrößern anklicken....

ArchLinux hat einen testing-Zweig. Dort verbringen kritische Pakete durchaus diverse Tage bis Wochen. Gerade der Kernel in einer .0 Revision kommt selten in den core-Zweig. Und ist ja nun nicht so als wenn ArchLinux von allen Paketen den git-Master nimmt. Man nimmt das, wo der Autor des Pakets sagte "das ist stabil". Das geht sehr oft gut, manchmal nicht (GCC 4.9 war so ein Kandidat)... aber man nutzt nun ArchLinux auch nicht, weil man LTS-Eigenschaften haben will.

Ich nutze auf dem Desktop ArchLinux seit mehreren Jahren (6 oder 7 schon), und hatte nur selten Probleme. Wenn es welche gab, waren die selten unlösbar. Und das auch produktiv (aka ich verdiene damit auch wirklich Geld). Und wenn ich mir so die ganzen Ubuntus meiner Kollegen angucke, dann haben die unterm Strich eher mehr Probleme als ich.

Ich finde es gut, dass ich nicht damit beschäftigt bin, mir dauernd neue Repositories einbinden zu müssen, oder mir fertig kompilierte Pakete von fragwürdigen Quellen einbinden muss... gerade so für mich essentielle Pakete wie PostgreSQL (zur Entwicklung). Ich brauch für meinen Desktop kein "How to install/upgrade to PostgreSQL 9.4 on ArchLinux"... für CentOS brauche ich das leider...

Und nein. Ich will nicht monatelang auf uralt-Software/Treibern sitzen mit ihren Bugs nur weil irgendwer meint "das ist stabiler".

darktrym schrieb:
Ich empfinde die Idee alle 6 Monate mal eine neue Version mittlerweile ganz entspannend. Besser wäre es natürlich nur einzelne Programme aktualisieren zu können, statt den gesamten, Verzeihung Rotz, von neuem. Ich hatte nicht das Gefühl das alle Server von der Geschwindigkeit und der akutellsten Pakete im Sync waren.
Zum Vergrößern anklicken....

Dann tue das doch. Hält dich ja keiner von ab. Darfst halt nur nicht ArchLinux nutzen...
 
goblin schrieb:
IMO liegt der Unterschied darin, dass die Nutzer gerne Bleeding Edge-Versionen der Software ihrer Wahl hätten, und die Maintainer (und ihr, Nuke&Azazyel) Bleeding Edge von allem.
Zum Vergrößern anklicken....

Nuke hat es schon erwähnt: hier ist die Erwartungshaltung der Nutzer das Problem. Arch Linux verspricht Bleeding Edge und liefert Bleeding Edge. Wenn man ein konservatives System mit ein paar frischen Tupfern haben möchte, nimmt man halt ein Debian stable mit einem Schuss testing oder ähnliches.

goblin schrieb:
IMO eine Frage der Zeitspanne. Aber wenn deine Kunden das mitmachen -- bitte.
Zum Vergrößern anklicken....

Ich persönlich bevorzuge den sanften Migrationsdruck - der Kunde kann alte Software solange nutzen wie er möchte, die Wartungs- und Lizenzkosten werden für alte Versionen aber von Jahr zu Jahr deutlich teurer. Entweder migriert der Kunde auf eine neuere Version oder er zahlt so deftige Summen, dass sich der Aufwand für die Wartung alter Versionen auch lohnt.
Wie üblich hängt das aber stark vom Umfeld und den Kunden ab - ein Thema für einen anderen Thread.

goblin schrieb:
Für die meiste Desktop-Software hat der X-Hack funktioniert, und wenn dann sollte man das doch sowieso in X11 (oder vielleicht mal X12, nach wieviel Jahrzehnten?) richten.
Zum Vergrößern anklicken....

Hast du dir mal den historisch gewachsen Verhau X11 unter der Haube angeschaut? Irreparabel.

goblin schrieb:
Ist die Frage, ob ich wirklich eine Korrektur von genau den Leuten haben möchte, die das ursprüngliche Konzept augenscheinlich schon vergeigt haben.
Zum Vergrößern anklicken....

Der Desktop ist nicht umsonst seit 2 Jahrzehnten die Achillesferse unter Unix. Immerhin konnte niemand zwischenzeitlich eine bessere Lösung auf die Beine stellen.

goblin schrieb:
Aber nein, die wollen ja lieber alles schon vorhandene wegschmeißen und neu schreiben.
Zum Vergrößern anklicken....

In diesem Fall sollte sich jemand finden lassen, der auf den vorhandenen Programmen aufsetzt und daraus eine Lösung macht, die besser ist als systemd-logind. Ich würde nicht darauf wetten.

goblin schrieb:
Dass dabei die Portabilität auf der Strecke bleibt ist für dich der Lauf der Dinge, ich sehe dahinter allerdings eine Agenda.
Zum Vergrößern anklicken....

Ich habe lieber gute systemspezifische als schlechte portable Implementierungen. Beruflich hatte ich bereits das Vergnügen, systemnahen C/C++-Code zu entwickeln, der in der ersten Version auf drei unterschiedlichen Plattformen laufen musste. Portabilität gibt es nicht umsonst.

Würdest du an Stelle der systemd-Entwickler den zigfachen Aufwand für eine portable Lösung treiben? Wie würdest du zwingend benötigte Features wie cgroups abbilden, so dass sie auch unter Plan 9 und NetBSD laufen?

goblin schrieb:
Das ist einem Editierfehler geschuldet, tut mir Leid. Drei Frameworks (policykit, polkit, systemd-logind) → zwei API-Brüche (policykit → polkit, polkit → systemd-logind). Hab an meiner Antwort gefeilt und da ist mir offensichtlich diese Mengenangabe durch die Lappen gegangen.
Zum Vergrößern anklicken....

Kein Stress - ich wollte nur vermeiden, dass ich etwas in der verworrenen Historie des Unix-Desktops übersehe.

goblin schrieb:
Mich würde ja mal interessieren, inwiefern sich die Anforderungen tatsächlich geändert haben, wie du ständig behauptest.
Zum Vergrößern anklicken....

Wie du selber sagst: "Dass das Session-Management nicht funktioniert hat sehe ich auch so"

ConsoleKit wurde 2007 gestartet. Im Jahre 2015 erwarte ich Kleinigkeiten wie ordentliche Multi-Seat-Unterstützung, vernünftiges Handling der Sessions u.a. beim Shutdown und zuverlässiges Aufräumen der Sessions beim Logout.
 
Azazyel schrieb:
Hast du dir mal den historisch gewachsen Verhau X11 unter der Haube angeschaut? Irreparabel.
Zum Vergrößern anklicken....
Ja, habe ich (Das Video [noch] nicht, den Code und die API schon). Und alle Alternativen sind bislang daran gescheitert, dass sie inkompatible Änderungen einführen wollten und niemand migrieren wollte. Was meinst du, warum ich so auf Rückwärtskompatibilität rumhacke? Dieses systemd-wayland-mir-Unix-Desktop Desaster verdanken wir IMHO der Hegemonie von freedesktop.org, wo seit Jahren alle Vorschläge von GNOME blockiert werden, die sie nicht selber spezifiziert haben (jüngstes mir bekanntes Beispiel: libnotification, kam von KDE und wurde von Canonical mit aufgegriffen, GNOME hat es blockiert, und das war wohl einer der Gründe warum sie Unity von GNOME geforkt haben). Standardkomitees können eben Fluch und Segen zugleich sein.

Azazyel schrieb:
Der Desktop ist nicht umsonst seit 2 Jahrzehnten die Achillesferse unter Unix. Immerhin konnte niemand zwischenzeitlich eine bessere Lösung auf die Beine stellen.
Zum Vergrößern anklicken....
Was aber vornehmlich aus politischen Gründen gescheitert ist, s.o.

Azazyel schrieb:
In diesem Fall sollte sich jemand finden lassen, der auf den vorhandenen Programmen aufsetzt und daraus eine Lösung macht, die besser ist als systemd-logind. Ich würde nicht darauf wetten.
Zum Vergrößern anklicken....
Und dann müsste es auch noch in GNOME integriert werden. Daran habe ich auch, trotz anderslautender Lippenbekenntnisse, persönliche Zweifel, dass das auch tatsächlich gemacht würde. Die Maintainer wollen „ihre“ Software nicht „hergeben“, haben aber auch keine Lust, fremden Code zu warten. Dann muss man forken? Ich weiß nicht, ob das tatsächlich gut gehen würde und vermutlich bin ich nicht der einzige, der so denkt. Immerhin wurde systemd schon durch uselessd imitiert, aber eine alternative API zu systemd-logind?

Azazyel schrieb:
Ich habe lieber gute systemspezifische als schlechte portable Implementierungen. Beruflich hatte ich bereits das Vergnügen, systemnahen C/C++-Code zu entwickeln, der in der ersten Version auf drei unterschiedlichen Plattformen laufen musste. Portabilität gibt es nicht umsonst.
Zum Vergrößern anklicken....
Wenn man unter Portabilität nur „#if defined(__LINUX__) #elsif defined(__FreeBSD) #else #endif“ versteht, dann kann ich mir das vorstellen.
Ich finde aber, wenn man Portabilität gut durchdacht hat, dann wirkt sie sich positiv auf die allgemeine Codequalität aus, weil die Abstraktionen „natürlicher“ verlaufen.

Azazyel schrieb:
Würdest du an Stelle der systemd-Entwickler den zigfachen Aufwand für eine portable Lösung treiben? Wie würdest du zwingend benötigte Features wie cgroups abbilden, so dass sie auch unter Plan 9 und NetBSD laufen?
Zum Vergrößern anklicken....
Ich würde mir definitiv Gedanken machen, ob ich Subsysteme, welche ganz allgemein X11-basierte Desktops als Klienten haben, so einfach auf plattformspezifische APIs festnagle, ja. Ich hätte zumindest versucht, systemd-logind so modular zu machen, dass er nicht unbedingt auf dem ganzen Rest aufbaut, der cgroup nutzt. Ich hätte allerdings auch nicht alle Funktionalität in PID 1 gestopft…

OT: Plan 9 passt IMHO nicht in die Liste, dort gibt es kein X11. Und es hatte native per process namespaces AFAIK schon vor Linux, da dürften sich cgroups vermutlich etwas einfacher emulieren lassen. Aber Plan 9 war schon ein tolles System… :)

Azazyel schrieb:
Wie du selber sagst: "Dass das Session-Management nicht funktioniert hat sehe ich auch so"
Zum Vergrößern anklicken....
Ich hatte aber noch den Zusatz dabei, dass eben Pulse-Audio und Gstreamer diejenige Software ist, welche die meisten Probleme mit Session-Management verursacht.

Azazyel schrieb:
ConsoleKit wurde 2007 gestartet. Im Jahre 2015 erwarte ich Kleinigkeiten wie ordentliche Multi-Seat-Unterstützung, vernünftiges Handling der Sessions u.a. beim Shutdown und zuverlässiges Aufräumen der Sessions beim Logout.
Zum Vergrößern anklicken....
Gut, dann mache ich es mal wie die systemd-Apologeten, vielleicht kannst du dann auch ein bisschen nachvollziehen, wie es mir die ganze Zeit geht: Bei mir hat Multiseat mit KDE ziemlich zuverlässig funktioniert, mit Ausnahme von Pulse-Audio. Ich habe keine Defizite beim Session-Handling feststellen können, außer dass man nach der ersten Session keinen Sound mehr hatte, weil Pulse-Audio irgendwo hängen geblieben ist.
Seit ich kein KDE mehr nutze brauchte ich auch kein Session-Handling mehr, aber davor hat es für mich einwandfrei funktioniert.
Außer PulseAudio eben. Von wem war das nochmal? Ach…
Und da wunderst du dich, dass ich systemd nicht zutraue, das Problem zuverlässig zu lösen?!
 
Azazyel schrieb:
Der Desktop ist nicht umsonst seit 2 Jahrzehnten die Achillesferse unter Unix. Immerhin konnte niemand zwischenzeitlich eine bessere Lösung auf die Beine stellen.
Zum Vergrößern anklicken....

Nur mal als Anmerkung dazu.
Ich benutze jetzt seit einigen Wochen / Monaten recht regelmäßig CDE.
Das einzige, was mir dabei auf den Senkel geht ist seine dauerhafte Anforderung von aller CPU-Power, die er scheinbar irgendwo rauskratzen kann. Es fehlen ein paar nette Tools, die es unter Solaris e.a. noch gab zum Management des Systems.
Ansonsten ein stabiler Desktop, der alles erfüllt und abarbeitet, was ich ihm zum Fraß hingeworfen habe.

Sieht halt nicht aus wie Windows, Gnome oder KDE, muß es aber auch nicht. Eine Achillesferse ist es aber IMHO auch nicht.
 
peterle schrieb:
Sieht halt nicht aus wie Windows, Gnome oder KDE, muß es aber auch nicht. Eine Achillesferse ist es aber IMHO auch nicht.
Zum Vergrößern anklicken....

Er meinte damit sicherlich nicht "es funktioniert nicht"... Xorg ist einfach ein riesen großes Sicherheitsloch, ein Flickenteppich und eine Ansammlung von Workarounds.

Nicht umsonst gibt es 3-5 verschiedene Ansätze wie man versucht die Darstellungsgeschwindigkeit zu erhöhen... UXA, SNA, GLAMOUR und wie sie nicht alle heißen. Alles nur Flickwerk, um das grundlegende Problem zu verharmlosen. Und ich hab z.B. bei Multimonitor auf dem Zweitbildschirm Tearing...

Nicht zuletzt das Problem, dass du Schwierigkeiten haben wirst, einen beschleunigten Desktop zu kriegen, wenn du mal was anderes als einen Desktop PC bekommst. Raspberry Pi lässt grüßen. Mit Xorg ein Krampf. Mit Wayland sogar benutzbar.

Siehe zum Beispiel das hier:
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Und Wayland hat es jetzt auch endlich geschafft, dass Leute auf den Zug aufspringen. GNOME und KDE werden wahrscheinlich noch dieses Jahr zu 100% auf Wayland laufen können. GNOME tut es jetzt schon zum großen Teil.

Klar bin ich auch nicht mit ALLEN Wegen einverstanden, die der Linux-Desktop so geht. Aber solange ich mich nicht hinsetze und einen entsprechenden Gegenvorschlag ausarbeite/einen Prototypen erstelle, bin ich halt auch ruhig. Ein bisschen meckern, ja. Aber auf Krampf Abstand halten? Nunja... solange es im Endeffekt noch funktioniert. systemd war am Anfang grausam und die Entwickler davon sind es immer noch. Aber jetzt, nachdem es mehrere Leute nutzen... nicht perfekt, aber auch nicht unbedingt schlechter als andere Init-Systeme. Viele Kritikpunkte sind auch wirklich optional (dieser ganze timesyncd etc. Schwachsinn z.b.).
 
Golem beschreibt es schlecht. Bisher hatte systemd nur ein spezielles Target, was ausgelöst wurde, wenn der Nutzer Strg-Alt-Entf drückte. In Standardeinstellung ist es ein Alias für das Reboot-Target, löst also einen normalen Reboot aus. Das Problem bei diesem Ansatz ist allerdings, dass es nur solange funktioniert, wie systemd selbst noch zu einem ordentlichen Reboot fähig ist. Wenn systemd sich aber z.B. beim Herunterfahren des Systems verheddert, was im derzeitigen Zustand leider gefährlich oft vorkommt, muss man den Reset-Knopf drücken. 7x Strg-Alt-Entf in 2 Sekunden (was in meinen Augen doch etwas häufig in kurzer Zeit ist) weißt systemd an alle Target zu ignorieren, die Dateisysteme zu unmounten und dann den Reboot auszulösen. Es ist also sozusagen ein Hack, um ein nicht mehr sauber neustartbares System noch halbwegs sauber heruntergefahren zu bekommen. Dürfte in der Praxis weitgehend äquivalent zum Magic SysRQ Alt-Druck + SUB sein.
 
"This will be used for interactive progress report and cancelling in plymouth."

Die arme Stadt, womit hat die das verdient?
 
Man muss dabei jetzt aber auch langsam wirklich unterscheiden, was Probleme des Init-Systems sind und was einfach nur zusätzliche Module sind. Sachen wie -networkd, -timesyncd, der Docker-Container Kram etc. sind alles Sachen die haben mit dem Init-System relativ wenig zu tun. Die sind im Default-Zustand abgeschaltet und behelligen einen so gar nicht. Sie laufen auch nicht als PID1, sondern sind nur teils schlecht implementiere Dienste die alle über eine einheitliche API (dbus) verfügen.

Kritikpunkte sind halt wirklich noch "die alten" Sachen wie das Log-Handling oder hier und da diese oder jene race condition...
 
-Nuke- schrieb:
Man muss dabei jetzt aber auch langsam wirklich unterscheiden, was Probleme des Init-Systems sind und was einfach nur zusätzliche Module sind. Sachen wie -networkd, -timesyncd, der Docker-Container Kram etc. sind alles Sachen die haben mit dem Init-System relativ wenig zu tun. Die sind im Default-Zustand abgeschaltet und behelligen einen so gar nicht. Sie laufen auch nicht als PID1, sondern sind nur teils schlecht implementiere Dienste die alle über eine einheitliche API (dbus) verfügen.
Zum Vergrößern anklicken....

Sehe ich nicht so, das systemd-Projekt zieht einen Haufen essenzieller Systemdienste an sich, und in vielen Distributionen sind sie per default auch an.
Na klar sagen die systemd-Verfechter wieder, das ist ja nicht die Schuld von systemd sondern von den Distributionen. Aber ich finde, das Assimilieren von Systemdiensten ist durchaus ein Problem auf der Seite von systemd. Wenn man diese Dienste anbietet, dann werden sie natürlich genutzt.
Die Argumentation, man kann ja andere Implementierungen nutzen, man muss nicht das nehmen was systemd bietet, ist wie schon bei der Einführung: "Ihr müsst systemd nicht nutzen, wenn ihr nicht wollt, aber alles andere ist deprectated und jeder nutzt systemd."
Zumindest mir kommt das reichlich schizophren vor.

Und die Hauptkritik an Systemd ist ja eben, dass es kein Init-System (mehr) ist sondern ein svchost für Linux. Das Ding tut zu viel, und das meiste dann auch noch schlecht.
 
goblin schrieb:
Und die Hauptkritik an Systemd ist ja eben, dass es kein Init-System (mehr) ist sondern ein svchost für Linux. Das Ding tut zu viel, und das meiste dann auch noch schlecht.
Zum Vergrößern anklicken....

Naja, ne. Mal so ganz trocken betrachtet:
Das "init" systemd (PID 1) ist nichts weiter als ein Init-System. Ein komplexes, ja, aber wirklich nur ein Init-System.

Alle anderen Sachen sind "nicht PID 1" Dienste und somit generell austauschbar. Was bei mir gerade läuft:
Code: 
root       171  0.0  0.2 109456 47920 ?        Ss   14:50   0:00 /usr/lib/systemd/systemd-journald
root       205  0.0  0.0  34544  3040 ?        Ss   14:50   0:00 /usr/lib/systemd/systemd-udevd
root       360  0.0  0.0  15288  2420 ?        Ss   14:50   0:00 /usr/lib/systemd/systemd-logind

udevd ist das was damals unter viel Geschrei von systemd "assimiliert" wurde. Kann man jetzt halten wie man will, noch ist es weiterhin ein separates Projekt und kann durchaus ohne systemd betrieben werden. Man darf einfach vom namen "systemd-udevd" nicht ableiten, dass es systemd _braucht_. Das mag sich vllt. irgendwann ändern, aber wenn das in die Grütze geht, kann man immer noch den Gentoo-Fork davon nehmen. Kein Projekt "linkt" direkt gegen udevd. Das läuft eh alles über dbus. Austauschbar ohne Probleme.

journald ist scheiße und wird wohl auch scheiße bleiben. Aber auch hier nichts, wo eine Anwendung von "abhängig" wird. Der schreibt weiter an syslog. Und wenn mir die Art und Weise von journald nicht gefällt, dann bietet das Teil ohne Probleme die Möglichkeit an den Input an einen anderen Logging-Dienst zu senden.

logind. Ja hier haben wir nun ein kleines Problem... hiervon werden Anwendungen abhängig. Diese werden aber nur von logind abhängig und nicht von systemd. Denn logind löst bestehende Probleme sehr effizient und gut. Es ist nun durchaus verständlich, wenn Leute dies nutzen. Es ist hier auch durchaus möglich eine Non-Systemd Version davon zu entwickeln, aber aufgrund der Art und Weise wie logind die Probleme löst ist es halt auf "nicht-Linux" Systemen teils schwer die Probleme "so einfach" zu lösen. Hier ist dann oft noch Programmieraufwand "hinter den Kulissen" nötig, damit man ein Shim einsetzen kann.

All der andere Kram der hier so kritisiert wird sind Zusatzdienste die soviel mit dem Init-System zu tun haben, wie andere Dienste die nicht mit "systemd-" beginnen. Und von denen wird auch keine Anwendung abhängig. Das sind einfach nur Zusatzdienste. Die muss man echt nicht benutzen und sind auch im Standard nicht an.

Von daher halte ich es für unsinnig hier wegen jedem Dienst der in der systemd-Umgebung entwickelt wird gleich weiter rumzujammern. Denn systemd besteht nur aus diesen 4 Komponenten:

- init-System
- systemd-journald
- systemd-udevd
- systemd-logind

Und journald ist dabei sogar "umgehbar".

Alles andere sind einfach nur irgendwelche Dienste. Optional, standardmäßig aus und damit total irrelevant. PID1 zieht keine Docker-Container aus dem Netz, PID1 setzt deine Uhrzeit nicht neu, PID1 schreibt kein log, PID1 richtet auch nicht dein Netzwerk ein.

Ich bin auch kein "Fan" von systemd, aber ich merke schon, dass mehr gejammert wird, als eigentlich nötig ist.
 
Ich entwickle mich zunehmend zum fan von systemd. Und zwar, weil es schmerzhaft deutlich darauf hinweist, dass demokratie eben *nicht* immer und überall ein guter Ansatz ist.

Um's mal flockig zu formulieren: Weder das Rad noch die Glühbirne wurden per Volksabstimmung erfunden und entwickelt.

Alleine schon dafür liebe ich BSD. Benevolente Diktatur von nachweislich ausgesprochen fähigen Einzelnen oder Teams. Mal aus dieser Perspektive betrachtet kann man zu linux sagen, dass es auch dort (einige sehr wenige) sehr fähige Leute gibt, dass das aber ganz erheblich verwässert wird durch haufenweise Inkompetenz mit Stimmrecht. Oder eben auch mal, grob gesagt, durch Leute, die sehr fragwürdige Interessen von Firmen durchdrücken.
 
Update:

Mittlerweile ist man dabei den Kern von Linux schlechthin zu zerballern. Linus hat nun unter beträchtlichem politischen Druck eine Art Nettigkeits-Verpflichtung unterschrieben.

Und wer taucht im Hintergrund hinter einem recht dünnen Verschleierungsmäntelchen aus eff und linux und open source politikern als die Strippenzieherin auf? Sara Dingsbums, ihr wisst schon, die die Linus vor einer Weile frontal angegangen ist von wegen sensiblere Leute würden durch Linus' ruppige Art vom Mitmachen beim kernel abgehalten.

Nebenbei hat sich mittlerweile noch herausgestellt, dass das kein bisschen "spontan" war, sondern geplant und vorbereitet. Zwar im Hintergrund aber wesentlich mit dabei: ada-irgendwas, der Schneckchen "diversity" Sturmtrupp. Kräftig unterstützt von kroah hartman, der nicht das erste Mal politik über linux gestellt und hinterhältige Machenschaften unterstützt hat.

Mein Tip an die linuxer: Ihr braucht noch mehr gender Experten und eine linux lgbt Bewegung! Dringend!
 
-Nuke- schrieb:
Man muss dabei jetzt aber auch langsam wirklich unterscheiden, was Probleme des Init-Systems sind und was einfach nur zusätzliche Module sind. Sachen wie -networkd, -timesyncd, der Docker-Container Kram etc. sind alles Sachen die haben mit dem Init-System relativ wenig zu tun. Die sind im Default-Zustand abgeschaltet und behelligen einen so gar nicht. Sie laufen auch nicht als PID1, sondern sind nur teils schlecht implementiere Dienste die alle über eine einheitliche API (dbus) verfügen.
Zum Vergrößern anklicken....

Naja, das ist zwar das Argument, aber wenn man zum Beispiel timesyncd durch openntpd ersetzen will kommt man an timedatectl nicht vorbei und um mal, subjektiv und aus meiner persönlichen Einzelfallerfahrung zu sprechen ist dann das Problem dort. timesyncd funtktioniert out of the box, aber mit openntpd gab's da recht komisches verhalten, also lass ich das nurnoch auf nicht-systemd laufen.
 
-Nuke- schrieb:
Also bei mir mit ntpd hab ich keinen Stress. :) Aber gut, Probleme kann es immer überall geben.
Zum Vergrößern anklicken....

Könnte es vielleicht damit zusammenhängen, dass "normaler" ntpd-Support quasi fest in systemd reincodiert wurde?
Das stört mich an den ganzen Behauptungen, die config sei so viel kürzer und einfacher, nämlich gewaltig: es geht nur noch, was seitens systemd vorgesehen ist. Irgendwo muss die Logik ja hinwandern, wenn sie aus den Kontrollskripten verschwindet.
Openntpd ist relativ neu, und vermutlich auf Linux recht unbekannt, so dass sich niemand Gedanken gemacht hat, was dafür eigentlich gebraucht wird.
Das sind aber alles nur Vermutungen.
 
Also ich hab mich jetzt mal interessehalber eingelesen und konnte keine Probleme irgendwo finden. Auch keine Abhängigkeiten zwischen dem NTP Dienst und systemd.

timedatectl set-ntp false

deaktiviert timesyncd (ist standardmäßig aus).

Und jetzt kann darauf jeder x-beliebige ntp-Dienst gestartet werden und gut ist. Ruft man jetzt timedatectl status auf, kommt so eine Ausgabe:

Code: 
     Local time: Sa 2015-03-14 00:34:34 CET
  Universal time: Fr 2015-03-13 23:34:34 UTC
        RTC time: Fr 2015-03-13 23:34:34
       Time zone: Europe/Berlin (CET, +0100)
     NTP enabled: no
NTP synchronized: yes
RTC in local TZ: no
      DST active: no
Last DST change: DST ended at
                  So 2014-10-26 02:59:59 CEST
                  So 2014-10-26 02:00:00 CET
Next DST change: DST begins (the clock jumps one hour forward) at
                  So 2015-03-29 01:59:59 CET
                  So 2015-03-29 03:00:00 CEST

An NTP synchronized sieht man, dass die Uhr gestellt ist. Das hat dann ntpd gemacht. Sollte bei openntpd nicht anders sein. systemd hat damit dann relativ wenig zu tun.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben