Dirk
fs4000 schriebMöchtest du nicht, dass ein typischer Windows-Nutzer auch in seinem Linux die Zeit einstellen kann?
Vom Prinzip her richtig, aber die Frage ist: braucht er das überhaupt?
Die Zeit(server)-Einstellungen werden bei der Installation vorgenommen. Der Hostname wird zu diesem Zeitpunkt ebenfalls gesetzt. Und wie oft ändert ein Windows-Nutzer den Hostnamen? Wenn er überhaupt weiß, was das ist … Zudem ist es selbst unter aktuellen Windows-Systemen nicht mehr nötig, an den Zeiteinstellungen rumzufummeln (zumal das schnell zu Inkonsistenzen führen kann – auch bei Windows!).
open-source greg
Was waren das noch für Zeiten in den man seinen hostname und seine Zeiteinstellungen, ganz umständlich, in einer Zentralen Datei treffen musste!
Creshal
Dirk Sohler schriebfs4000 schriebMöchtest du nicht, dass ein typischer Windows-Nutzer auch in seinem Linux die Zeit einstellen kann?
Vom Prinzip her richtig, aber die Frage ist: braucht er das überhaupt?
Zumindest Zeitzone kann bei Laptops ganz praktisch sein.
Ovion
Warum eigentlich über Polkit? Ist der Rechte-Teil noch nicht fertig implementiert oder habe ich da was falsch verstanden? systemd sollte sich doch auch darum kümmern. Nicht, dass ich hier irgendwas forcieren wollen würde.
fs4000
Polkit bleibt, ConsoleKit wird durch systemd-logind ersetzt.
Ovion
Ok, dann nochmal die Frage, was was macht. Polkit soll für Berechtigungen zuständig sein, consolekit für Sessionmanagement und dafür, dass der User bspw. Datenträger mounten kann, ohne root zu sein. Aber müsste letzteres nicht in den Bereich von Polkit fallen? Wo genau ist die Trennlinie?
fs4000
ConsoleKit bzw systemd-logind tracken User-Sessions, was Polkit aufgreift, um die Rechte je nach Status (active, inactive, any) unterschiedlich zu behandeln. Die neueste Polkit Version unterstützt nur noch systemd-logind, weshalb ConsoleKit nun endgültig in den Ruhestand gehen kann.
Ovion
Heißt das für nicht-systemd-ler Polkit-nicht-upgrade oder systemd-logind ohne systemd-rest nutzen?
Und bevor wir zu weit vom Thema Socketactivation wegkommen: Was passiert eigentlich, wenn Programm A (wichtige) Daten an Programm B weitergibt, indem A diese einfach in den Socket von B wirft, was der Kernel ja puffert, bis B gestartet ist, dann aber B nicht startet, weil beim letzen Update ein Paket kaputtgegangen ist oder wasauchimmer? Sind die Daten dann verloren oder werden die in irgendwelche Logfiles geschrieben oder x? Könnte ja ein erhebliches Problem darstellen, falls A diese möglicherweise wichtigen Daten in der Vermutung, B hätte sie entgegengenommen, wegwirft, während B gar nicht funktioniert.
fs4000
Ovion schriebHeißt das für nicht-systemd-ler Polkit-nicht-upgrade oder systemd-logind ohne systemd-rest nutzen?
Die werden erhebliche Probleme bekommen, weil nichts mehr funktioniert. Unter anderem deshalb stellt Arch ja auf systemd als Standard um. Man könnte natürlich patchen oder Ähnliches, aber Arch ist KISS und deshalb systemd.
AFAIK bleibt der sendende Thread sowieso stehen und bekommt natürlich einen Fehler, worauf er dann mehr oder weniger angemessen reagieren kann. Ist alles eine Sache der Anwendungsprogramme. Es konnte ja schon vorher passieren, dass ein Socket nicht da war, weil der Dienst abgeschmiert ist.
Dirk
Creshal schriebZumindest Zeitzone kann bei Laptops ganz praktisch sein.
Die Masse der User wechselt nicht so oft zwischen verschiedenen Zeitzonen umher, als das es dafür extra einen Dienst geben müsste, der es ermöglicht, per GUI als User die Zeitzone zu ändern. Natürlich kann man für jede Funktion einen Anwendungsfall konstruieren, und für jeden Pipifax einen eigenen Daemon schreiben, aber die Frage ist: Wie fett soll systemd dann noch werden? Ist es sinnvoll, für einen einstelligen Prozentsatz an Usern, die eine spezielle Funktion benötigen >=91 Prozent der User den Kram mit aufzudrücken (und wenn es nur das Deaktivieren des Daemons ist)?
Ovion
fs4000 schriebOvion schriebHeißt das für nicht-systemd-ler Polkit-nicht-upgrade oder systemd-logind ohne systemd-rest nutzen?
Die werden erhebliche Probleme bekommen, weil nichts mehr funktioniert.
Wer ist denn auf die Idee gekommen, polkit systemd-only zu machen? Nix gegen systemd-support, aber warum lässt man jedwede Abwärtskompatiblität fahren?
fs4000 schriebAFAIK bleibt der sendende Thread sowieso stehen und bekommt natürlich einen Fehler, worauf er dann mehr oder weniger angemessen reagieren kann. Ist alles eine Sache der Anwendungsprogramme. Es konnte ja schon vorher passieren, dass ein Socket nicht da war, weil der Dienst abgeschmiert ist.
Aber wenn der Socket da ist und der Dienst dahinter nur nicht gestartet ist, dann gibt es doch, soweit ich das verstanden habe, keinen Fehler, sondern die Daten gelten als geschrieben. Der Kernel schreibt dann in den Dienst, sobald er gestartet ist. Der Socket ist ja da, unabhängig, ob der Dienst dahinter funktioniert oder nicht, oder irre ich da? Wenn dann der Dienst hinter'm Socket nicht startbar ist, dann können als geschrieben geltende Daten doch nicht geschrieben werden und wir haben den Salat. Oder habe ich einen Fehler in meinem Gedankengang bzw. missverstehe das Prinzip von Socketactivation?
Und warum wird das Setzen des Hostnamens und der Zeit über einen Socket gelöst? Wäre da ein eigenes Programm nicht sinnvoller? Dann braucht man nicht extra einen Socket aufzumachen.
OttoKrüja
Dirk Sohler schriebfs4000 schriebMöchtest du nicht, dass ein typischer Windows-Nutzer auch in seinem Linux die Zeit einstellen kann?
Vom Prinzip her richtig, aber die Frage ist: braucht er das überhaupt?
Natürlich, um die Shareware nach 30 Tagen weiter nutzen zu können!
fs4000
Nein, dazu gibts doch libfaketime.
runiq
=O
So simpel, so genial, und auf Linux meistens sowas von unnötig.
Astorek
Ich hab das für 'nen Witz gehalten, aber libfaketime gibts wirklich? 😮
Davon abgesehen: Es gibt zeitlich begrenzte Shareware unter Linux? Also solche, die als "Kopierschutz" die Systemzeit vergleichen?
Dirk
Astorek schriebDavon abgesehen: Es gibt zeitlich begrenzte Shareware unter Linux?
Zumindest keine offene. Aber geschlossene Fällt mir auch nicht ein … Es gibt sicher auch für Linux „Shareware“, aber deren Verbreitungsgrad dürfte im Promillebereich liegen 🙂
Creshal
Das braucht man zum Testen auf Jahr-2037-Kompatibilität!!1 😃
fs4000
Ovion
Statt d-bus in systemd zu mergen, wie es im Kommentar vorgeschlagen wird, wäre ich eher dafür, dass man in so einem Fall die Pakete auftrennt. Wozu gibt es denn Abhängigkeitsauflösung in der Paketverwaltung?
Das bestreben, einfach alles, was systemd braucht, in systemd hineinzumergen, halte ich für den falschen Weg, weil dadurch jeder, der z.B. d-bus braucht, gleich das komplette systemd ziehen muss. Selbes bei udev.
Das hat, wie es auch schon angesprochen wurde, die Tendenz "ihr braucht eine bestimmte Komponente, weil sie bisher immer frei verfügbar war? Jetzt gibt's sie aber nur im Paket mit x und y und z. Könnt ihr euch ja mitinstallieren, funktioniert sowieso nicht mehr ohne." Und ich habe das Gefühl, dass da ein "eigentlich würden wir diese Komponente noch mit technischen Prüfungen versehen, ob wirklich x, y und z auf dem System laufen" mitschwingt.
Finde ich sehr schade, weil das genau das Gegenteil der Art von Freiheit ist, für die Linux lange Zeit stand. Ich hoffe wirklich, dass das nicht der erste Schritt einer Entwicklung ist, wie so mancher hier bereits prophezeit hat.
So gute Ideen systemd einbringt, schwingt dieses latente "wenn du eine gute Sache davon haben möchtest, musst du gleich alle nehmen und deine bisherigen Lösungen in Rente schicken" mit.
Ich bin sehr gespannt, wie sich das weiterentwickeln wird. Ein Abhängigkeitszyklus zweier unabhängiger Dinge sollte durch Paketaufteilung gelöst werden und nicht durch alles zusammenmergen, was in Konflikt steht, denke ich. Sonst könnten wir auch gleich ein Paket "system" einführen.
Was ich nicht weiß ist, wieviel Aufwand ein gemergtes Paket gegenüber einer Paketaufteilung für den Paketmaintainer bedeutet, kann mir da jemand eine Einschätzung geben, wie es z.B. beispielhaft an diesem Fall aussieht? Das ist einer der Punkte, die ich aktuell noch schlecht beurteilen kann.
Army
Es ist aber nach wie vor so, dass systemd, wenn es zwar installiert ist, aber nicht verwendet wird, nur etwas Festplattenplatz einnimmt. Ich weiß, auch das ist störend, bin selbst Minimalist, aber die paar MB tun wirklich niemandem weh!