Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Nutzt schon jemand systemd?
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page Previous  1, 2, 3, 4, 5, 6  Next  
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Diskussionsforum
View previous topic :: View next topic  
Author Message
astaecker
Guru
Guru


Joined: 28 Apr 2003
Posts: 403
Location: Hamburg / Germany

PostPosted: Fri Jul 20, 2012 6:30 am    Post subject: Reply with quote

bell wrote:
Erstmal ist und war die Stärke von Linux immer die Vielseitigkeit. Man erinnere sich an die Microsoft-Werbe-Kampagne mit dem mutierten Pinguin, die nach Hinten losgegangen ist. Systemd und vieles andere, was von freedesktop.org unterstützt wird untergräbt diese Stärke. Und bald landen wir bei einem Volks-Linux, die einzig wahre Linux-Distribution!.

Differenzierung macht Sinn, wenn es was zu differenzieren gibt. Wenn viele Distros exakt gleiche Sachen machen, ist es doch sinnreich, ein Gemeinschaftsprojekt daraus zu machen und sich viel Arbeit zu ersparen. Als Paradebeispiel für ich hier mal den Linux Kernel an. Als Beispiel für sinnvolle Differenzierung Portage.

bell wrote:
Hier gebe ich @mv Recht. Gut konzipierte Software ohne Dämonen die gestartet werden müssen, würden den Boot-Vorgang noch mehr beschleunigen.

Daemonen werden häufig für systemweite Dienste genutzt, die erweiterte Rechte brauchen, so dass der Benutzer sie nicht selber starten kann. Mit den Sockets hat systemd schon eine gute Methode gefunden, viele Daemonen nur bei Bedarf zu starten.

bell wrote:
Wenn einem der schnelle Bootvorgang wichtig ist, der bearbeitet ihn zusätzlich mit e4rat.

Kein init Daemon ist bisher so schnell wie systemd. Und man sollte diesen Vorteil auch nicht herunterspielen, da es immernoch massenweise Benutzer gibt, die ihren PC herunterfahren anstatt S3 oder S4 zu nutzen.

bell wrote:
Auch Consolekit war eine Sache die man eigentlich nicht braucht. Ballast durch Ballast ersetzen ist für mich kein Vorteil.

Es gibt es etliche Anwendungsfälle, die nur durch Software wie ConsoleKit ermöglicht werden.

bell wrote:
Auch in der Closed-Source Welt hat man es schon begriffen: Die meisten Binär-Formate gehen Richtung Text-Dateien (XML oder ähnliches). Wir gehen rückwärts.

Wie gesagt, ist das Binär-Format quelloffen und damit bekannt, und nach einer Beta-Phase wollen sie es auch ausführlich dokumentieren (was sie wohl auch gewissentlich tun werden, da systemd hervorragend dokumentiert ist). Die berechtigten Vorbehalte vor der Closed-Source Welt treffen daher einfach nicht zu.

bell wrote:
Ich habe nichts gegen neue Konzepte. Jedoch sollten diese nicht so gepuscht werden dass andere Konzepte keine Chance mehr haben und die User keine Wahl mehr.

Anderen Konzepte haben eine Chance, z.B. hat sich busybox mit mdev als Alternative zu udev & Co entwickelt. Nur fehlt es oft an Entwicklern, die die anderen Konzepte auch realisieren, was aber nicht die Schuld von udev & Co Entwicklern ist.
Back to top
View user's profile Send private message
franzf
Advocate
Advocate


Joined: 29 Mar 2005
Posts: 3983
Location: Irgendwo im Nirgendwo

PostPosted: Fri Jul 20, 2012 7:19 am    Post subject: Reply with quote

astaecker wrote:
Differenzierung macht Sinn, wenn es was zu differenzieren gibt. Wenn viele Distros exakt gleiche Sachen machen, ist es doch sinnreich, ein Gemeinschaftsprojekt daraus zu machen und sich viel Arbeit zu ersparen.

Lol? systemd stammt von EINER Person, die für EINE Firma arbeitet. Da andere Projekte dieser EINEN Person sich dermaßen tief in aktuelle Desktops gefressen haben, ist es ihm problemlos möglich, allen sein system aufs Auge zu drücken. Das hat nix mit Gemeinschaft zu tun, das ist Diktatur! (Evtl. das "D" in SystemD?)

Quote:
Als Paradebeispiel für ich hier mal den Linux Kernel an.

Ohne Linux-Kernel hätte man kein Linux, damit auch keine Linux-Distribution. Nur weil viele Firmen sich an der Kernel-Entwicklung beteiligen, heißt das nicht dass sie das als "sinnvolles Gemeinschaftsprojekt" sehen und ansonsten einen eigenen Kernel schreiben würden. Der Kernel ist deren (nicht ausschließliche) Einnahmequelle.
_________________
"der mac dennoch wesen geil"
Wolfram von Eschenbach, Parzival (Buch 1, Z. 7).
Ein frühes Statement gegen Windows.

My overlay
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4349

PostPosted: Fri Jul 20, 2012 8:00 am    Post subject: Reply with quote

astaecker wrote:
Die Dateisystem-Rechte sind eine gute Grundlage, bieten aber keine feingliedrigere Rechtevergabe.

Es wäre billig, beim Einloggen und Ausloggen in X die Rechte passend zu ändern. Für die wenigen Szenarien, die noch feinere Rechte benötigen gibt es ACL.
Die richtige Lösung wäre, mit diesen Mitteln zu arbeiten statt Ressourcen zu verpulfern.
Quote:
Die beiden interagieren nicht miteinander, sondern laufen nur parallel zueinander.

Eben. Zwei parallel laufende Root-Dämonen, die an der selben Sache herumpfuschen und somit vermutlich hervorragende Angriffsvektoren (race conditions u.ä.) bieten.
Quote:
Beides macht ihn für mich nicht zu einem Kernentwickler.

Wer letztlich die Programmierarbeit macht, ist in diesem Zusammenhang ziemlich egal. Das Hauptproblem ist die zugrundeliegende Fehlkonzeption, und die klingt gerade nach dem üblichen Lennart-Zugang ("Um es sauber hinzubekommen, müsste man viele Programmen ändern - nö, machen wir nicht. Statt dessen hacken wir mal einen Daemon hin, mit dem es auf die Schnelle geht, auch wenn es Ressourcen frisst. Hmmm, jetzt muss man es doch in vielen Programmen ändern. Naja, dann ändern wir halt doch die Programme. Aber natürlich nicht so, dass sie es sauber machen, sondern den Daemon-Hack benutzen.")
Quote:
mv wrote:
Quote:
Vereinheitlichung von Konfigurationsdateien:

Das ist ein Vorteil eines distributionsabhängigen Systems. Wie beispielsweise OpenRC. Oder SystemV. Oder Systemd. Oder Upstart. Wo war noch mal der spezielle Vorteil von systemd? Vermutlich, dass Lennart für ständige Änderungen der eigenen Konfigurationsfile bekannt ist (siehe das HAL-Debakel u.ä.).

Irgendwie sprechen wir nicht über die gleiche Sache. Es macht doch Sinn, wenn man z.B. in /etc/locale distributionsunabhängig die Lokalisierung einstellen kann, anstatt sie bei Gentoo unter /etc/conf.d/... , bei Fedora unter /etc/default/... und bei OpenSUSE sonstwo zu finden.

Genauso würde es Sinn machen, die Lokalisierung überall unter /etc/conf.d zu finden. Warum sollte man - wenn man distributionsabhängig vereinheitlichen will - gerade die hackischste Lösung (Daemonen) nehmen, wenn es funktionierende gute gäbe?
Quote:
Das Journal ist optinal.

Wie oben beschrieben: Noch.
Und implizit stimmst Du also auch zu, dass das Geraffel vielleicht gerade dann noch akzeptabel ist, wenn man es ausschalten kann. Dann sollte es zuallererst einmal gar nicht programmiert werden.

Quote:
mv wrote:
Quote:
All-in-One Lösung / Missachtung Unix-Philosophie:
systemd intern gut strukturiert und hat sauberern Code

Was bitteschön hat eine interne Strukturierung eines Programms mit dem obigen Punkt zu tun? Abgesehen davon nützt bei einer Fehlplanung der Grundfunktionalität die schönste Strukturierung und Dokumentation der Details nichts.

Intern hat systemd etliche Module, die sauber voneinander getrennt sind.

Das hat mit der Tatsache, dass das Programm gegen den Willen des Administrators überall herumpfuscht genau was zu tun?
Quote:
Quote:
Es kann bei einem schnell zusammengeschusterten System als Notlösung dienen, aber eine ordentliche Distribution sollte solche Hacks vermeiden.

Das musst du weiter ausführen. Ich weiß nicht, wie du das genau meinst.

Das hatte ich schon mehrmals beschrieben: Durch sauberes Konfigurieren - das allerdings aufwändig sein kann und u.U. das Patchen mehrerer Programme bedeutet - kann man praktisch alle Daemonen vermeiden. Aber anstatt an einer solchen sauberen Lösung zu arbeiten, konzentriert sich systemd ausschließlich auf die Pfusch-Lösung.
Back to top
View user's profile Send private message
astaecker
Guru
Guru


Joined: 28 Apr 2003
Posts: 403
Location: Hamburg / Germany

PostPosted: Fri Jul 20, 2012 8:00 am    Post subject: Reply with quote

franzf wrote:
Lol? systemd stammt von EINER Person, die für EINE Firma arbeitet. Da andere Projekte dieser EINEN Person sich dermaßen tief in aktuelle Desktops gefressen haben, ist es ihm problemlos möglich, allen sein system aufs Auge zu drücken. Das hat nix mit Gemeinschaft zu tun, das ist Diktatur! (Evtl. das "D" in SystemD?)

Schön, dass ich deinen Morgen mit einem Lacher versüßen konnte :-)
Lennart hat nur Avahi, PulseAudio und systemd initiiert. Bei anderer Middleware - udev, udisks, upower, ConsoleKit, PolKit - ist nicht sein "Mist". Außerdem ist es schon ziemlich dreist, ihn als Diktator zu bezeichnen, nur weil er Code schreibt und andere (wer auch immer) nicht.

franzf wrote:
Ohne Linux-Kernel hätte man kein Linux, damit auch keine Linux-Distribution. Nur weil viele Firmen sich an der Kernel-Entwicklung beteiligen, heißt das nicht dass sie das als "sinnvolles Gemeinschaftsprojekt" sehen und ansonsten einen eigenen Kernel schreiben würden. Der Kernel ist deren (nicht ausschließliche) Einnahmequelle.

Es gibt noch andere Distributionen (BSD, Solaris, usw.), so dass Linux als Kernel schon eine Entscheidung der jeweiligen Distribution ist.
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1062
Location: Schweiz

PostPosted: Fri Jul 20, 2012 8:25 am    Post subject: Reply with quote

Ich glaube hier verrennen sich einige in etwas.
Das Problem ist doch eigentlich weniger das systemd diese Funktionalitäten anbietet sondern eher das manche andere Entwickler zu faul (oder was auch immer der Grund sein mag) sind dem Enduser die Wahl zu lassen ob er davon auch Gebrauch machen will oder eben nicht.

[ACHTUNG: Persönliche Behauptung]
Bestes Beispiel ist ja udisks das zwingend polkit (und somit auch consolekit und und und...) erfordert obwohl viele Enduser die daraus resultierend Möglichkeiten zur Feingliederung der Rechte gar nicht benötigen würden. Viele wollen doch einfach nur die Möglichkeit ein Volumen per Mausklick zu mounten ohne eine Konsole aufrufen zu müssen.
Die Entwickler hätten ja udisks so programmieren können das es auch ohne polkit funktionieren wurde und dann wenn es denn so installiert würde einfach alle darin enthaltenen Aktionen jedem User erlaubt der beispielsweise in der UNIX-Gruppe "disk" Mitglied ist.
[/ACHTUNG: Persönliche Behauptung]
_________________
Mich braucht jeder. Zumindest behaupten viele, ich hätte gerade noch gefehlt. ;)
GPG: 0x54A19454 - Download | (0x5E2B12A0 ist veraltet)
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4349

PostPosted: Fri Jul 20, 2012 10:14 am    Post subject: Reply with quote

schmidicom wrote:
Bestes Beispiel ist ja udisks das zwingend polkit (und somit auch consolekit und und und...) erfordert obwohl viele Enduser die daraus resultierend Möglichkeiten zur Feingliederung der Rechte gar nicht benötigen würden. Viele wollen doch einfach nur die Möglichkeit ein Volumen per Mausklick zu mounten ohne eine Konsole aufrufen zu müssen.
Die Entwickler hätten ja udisks so programmieren können das es auch ohne polkit funktionieren wurde und dann wenn es denn so installiert würde einfach alle darin enthaltenen Aktionen jedem User erlaubt der beispielsweise in der UNIX-Gruppe "disk" Mitglied ist.

Genau das ist der Punkt: Die vermeintlich freie Software ist nämlich nicht wirklich frei. Zwar steht es theoretisch jedem frei, udisks umzuprogrammieren, aber in der Praxis ist ohne dauerhafte Geldgeber ein solcher Versuch sinnlos, weil man diese Software dann dauerhaft warten müsste, denn kein großes Projekt setzt auf ungewartete Software.
Dass udisks die obige Lösung nicht wählt, liegt ziemlich wahrscheinlich nicht an der "Faulheit" der udisks-Programmierer oder dass sie keine Patches für diese Änderung bekämen, sondern an der Politik. Ob jetzt Poettering persönlich dahintersteckt oder irgendjemand anderes von Redhat kann ich nicht sagen, aber es ist seit geraumer Zeit offensichtlich, dass Möglichkeiten, die Poettering-Daemonen zu umgehen, politisch sehr geziehlt ausgeschaltet werden.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4349

PostPosted: Fri Jul 20, 2012 10:29 am    Post subject: Reply with quote

astaecker wrote:
Lennart hat nur Avahi, PulseAudio und systemd initiiert. Bei anderer Middleware - udev, udisks, upower, ConsoleKit, PolKit - ist nicht sein "Mist".

Das ist nicht so klar. Die ausführenden Programmierer sind nicht unbedingt die Initiatoren. Aber ich will durchaus zugestehen, dass es möglich ist, dass nicht Poettering selbst sondern irgendjemand anderes (oder gar eine Programmierer-"Kommission" bei Redhat) diese Fehlkonzepte verbrochen hat. Allerdings vertritt Poettering sie öffentlich ziemlich massiv und scheint deshalb der richtige "Ansprechpartner" dafür zu sein.
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1062
Location: Schweiz

PostPosted: Sat Oct 13, 2012 11:14 am    Post subject: Reply with quote

Ich wollte mal systemd antesten (um noch besser darüber jammern zu können ;) ) doch installiert bekomme ich es nicht wirklich wegen einem udev update mit einem seltsamen block:
Code:
# emerge --update -av udev
                                                                                                                   
These are the packages that would be merged, in order:                                                             
                                                                                                                       
Calculating dependencies... done!                                                                                         
[ebuild     U ~] sys-fs/udev-194 [171-r6] USE="acl%* gudev hwdb openrc%* -doc% -introspection -keymap (-selinux) -static-libs% (-action_modeswitch%) (-build%) (-debug%) (-edd%) (-extras%*) (-floppy%) (-rule_generator%*) (-test%)" 1,378 kB                 
[ebuild  N    ~] sys-fs/udev-init-scripts-16  5 kB
[blocks B      ] <sys-fs/udev-186 ("<sys-fs/udev-186" is blocking sys-fs/udev-init-scripts-16)

Total: 2 packages (1 upgrade, 1 new), Size of downloads: 1,383 kB
Conflict: 1 block (1 unsatisfied)

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

sys-fs/udev:0

  (sys-fs/udev-171-r6::gentoo, installed) pulled in by
    <sys-fs/udev-185 required by (net-wireless/bluez-4.99::gentoo, installed)

  (sys-fs/udev-194::gentoo, ebuild scheduled for merge) pulled in by
    >=sys-fs/udev-187 required by (sys-fs/udev-init-scripts-16::gentoo, ebuild scheduled for merge)


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.

Wie kann man das lösen?
_________________
Mich braucht jeder. Zumindest behaupten viele, ich hätte gerade noch gefehlt. ;)
GPG: 0x54A19454 - Download | (0x5E2B12A0 ist veraltet)
Back to top
View user's profile Send private message
franzf
Advocate
Advocate


Joined: 29 Mar 2005
Posts: 3983
Location: Irgendwo im Nirgendwo

PostPosted: Sat Oct 13, 2012 11:42 am    Post subject: Reply with quote

bluez aus testing installieren.
_________________
"der mac dennoch wesen geil"
Wolfram von Eschenbach, Parzival (Buch 1, Z. 7).
Ein frühes Statement gegen Windows.

My overlay
Back to top
View user's profile Send private message
Dr. Strangelove
Tux's lil' helper
Tux's lil' helper


Joined: 01 May 2006
Posts: 104
Location: Germania

PostPosted: Sat Oct 13, 2012 11:48 am    Post subject: Reply with quote

schmidicom wrote:
... doch installiert bekomme ich es nicht wirklich wegen einem udev update mit einem seltsamen block:

[blocks B ] <sys-fs/udev-186 ("<sys-fs/udev-186" is blocking sys-fs/udev-init-scripts-16)
...

(sys-fs/udev-171-r6::gentoo, installed) pulled in by
<sys-fs/udev-185 required by (net-wireless/bluez-4.99::gentoo, installed)

(sys-fs/udev-194::gentoo, ebuild scheduled for merge) pulled in by
>=sys-fs/udev-187 required by (sys-fs/udev-init-scripts-16::gentoo, ebuild scheduled for merge)


Der erste Block löst sich mit einem zwischenzeitlichen "emerge -C udev", da du udev-171-r1 installiert hast und das udev-194 will nun das paket udev-init-scripts, aber erst ab der Version udev-186 wurden diese scripts herausgelöst. Dieser Block vermeidet file-collisions.
Der zweite Block löst sich mit dem emerge von bluez-4.101-r3, du hast bluez-4.99 installiert, das will aber ein udev kleiner als 185.

Ach ja, weil ich es mir nicht verkneifen kann, der Oberlehrer im Fach Gentoo (eher wohl Englisch und Mathe) würde sagen: "Sechs, setzen bitte!" :-D

Anekdotisch dazu, unser Lehrer in Mathe hatte tatsächlich Karten mit den Zensuren 1-6 in der Brusttasche seines Hemdes, und musste er einmal diese böse Zensur vergeben, zog er sie heraus und sagte "Sie wissen, welcher Spruch jetzt kommt!"
Back to top
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 2303
Location: Germany

PostPosted: Sat Oct 13, 2012 12:28 pm    Post subject: Reply with quote

Dr. Strangelove wrote:
schmidicom wrote:
... doch installiert bekomme ich es nicht wirklich wegen einem udev update mit einem seltsamen block:

[blocks B ] <sys-fs/udev-186 ("<sys-fs/udev-186" is blocking sys-fs/udev-init-scripts-16)
...

(sys-fs/udev-171-r6::gentoo, installed) pulled in by
<sys-fs/udev-185 required by (net-wireless/bluez-4.99::gentoo, installed)

(sys-fs/udev-194::gentoo, ebuild scheduled for merge) pulled in by
>=sys-fs/udev-187 required by (sys-fs/udev-init-scripts-16::gentoo, ebuild scheduled for merge)


Der erste Block löst sich mit einem zwischenzeitlichen "emerge -C udev", da du udev-171-r1 installiert hast und das udev-194 will nun das paket udev-init-scripts, aber erst ab der Version udev-186 wurden diese scripts herausgelöst. Dieser Block vermeidet file-collisions.
Der zweite Block löst sich mit dem emerge von bluez-4.101-r3, du hast bluez-4.99 installiert, das will aber ein udev kleiner als 185.

Ach ja, weil ich es mir nicht verkneifen kann, der Oberlehrer im Fach Gentoo (eher wohl Englisch und Mathe) würde sagen: "Sechs, setzen bitte!" :-D

Anekdotisch dazu, unser Lehrer in Mathe hatte tatsächlich Karten mit den Zensuren 1-6 in der Brusttasche seines Hemdes, und musste er einmal diese böse Zensur vergeben, zog er sie heraus und sagte "Sie wissen, welcher Spruch jetzt kommt!"

Hm nein, das deinstallieren von udev sollte nicht nötig sein (ich würde auch davon abraten). Sofern die geforderten Abhängigkeiten bezüglich bluez erfüllt werden können nimmt portage das udev Upgrade selbst vor, da dann der Block gar nicht erst entsteht.
Sprich, geforderte Abhängigkeiten erfüllen - und dann ganz normal aktualisieren sollte problemlos funktionieren.

Edit sagt, das schaut dann zb so aus:
Code:
# emerge -av1 udev bluez

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] sys-apps/kmod-10  USE="tools zlib -debug -doc -lzma -static-libs" 0 kB
[uninstall     ] sys-apps/module-init-tools-3.16-r1  USE="-static"
[blocks b      ] sys-apps/kmod ("sys-apps/kmod" is blocking sys-apps/module-init-tools-3.16-r1)
[blocks b      ] sys-apps/module-init-tools ("sys-apps/module-init-tools" is blocking sys-apps/kmod-10)
[ebuild  N     ] sys-fs/udev-init-scripts-16  0 kB
[ebuild     U  ] sys-fs/udev-194 [171-r6] USE="acl%* gudev hwdb keymap openrc%* -doc% -introspection (-selinux) -static-libs% (-action_modeswitch%) (-build%) (-debug%) (-edd%) (-extras%*) (-floppy%) (-rule_generator%*) (-test%)" 0 kB
[blocks b      ] <sys-fs/udev-186 ("<sys-fs/udev-186" is blocking sys-fs/udev-init-scripts-16)
[ebuild  N     ] net-wireless/bluez-4.101-r3  USE="alsa consolekit cups gstreamer readline -debug -pcmcia (-selinux) -test-programs -usb" 0 kB

Total: 4 packages (1 upgrade, 3 new, 1 uninstall), Size of downloads: 0 kB
Conflict: 3 blocks

Would you like to merge these packages? [Yes/No] n

Quitting.
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1062
Location: Schweiz

PostPosted: Sat Oct 13, 2012 1:43 pm    Post subject: Reply with quote

Das mit bluez hat geholfen, sorry habe das irgenwie übersehen, und das neue udev ist nun drauf zusammen mit systemd.

Leider bootet mein Gentoo damit nicht vollständig, ein par dinge scheinen da noch unzufrieden zu sein.
Code:
#systemctl --all --full
UNIT                        LOAD    ACTIVE    SUB
auditd.service              error   inactive  dead
display-manager.service     error   inactive  dead
plymouth-quit-wait.service  error   inactive  dead
plymouth-start.service      error   inactive  dead
syslog.service              error   inactive  dead
systemd-logind.service      loaded  failed    failed
dbus.socket                 error   inactive  dead

Das grösste Problem hier dürfte wohl der dbus sein da dieser heutzutage ja von so ziemlich allem gebraucht wird.

EDIT:
Nach einem neubauen von dbus ist es nur noch das:
Code:
#systemctl --all --full
UNIT                        LOAD    ACTIVE    SUB
auditd.service              error   inactive  dead
display-manager.service     error   inactive  dead
plymouth-quit-wait.service  error   inactive  dead
plymouth-start.service      error   inactive  dead
syslog.service              error   inactive  dead

_________________
Mich braucht jeder. Zumindest behaupten viele, ich hätte gerade noch gefehlt. ;)
GPG: 0x54A19454 - Download | (0x5E2B12A0 ist veraltet)
Back to top
View user's profile Send private message
franzf
Advocate
Advocate


Joined: 29 Mar 2005
Posts: 3983
Location: Irgendwo im Nirgendwo

PostPosted: Sat Oct 13, 2012 2:33 pm    Post subject: Reply with quote

Dann schau mal, wer diese ".service" files installiert (sollten in /usr/lib64/systemd/* liegen), und bau die Pakete neu - vielleicht geht es ja dann wie nach dem dbus-Neubau.
Quote:
Das grösste Problem hier dürfte wohl der dbus sein da dieser heutzutage ja von so ziemlich allem gebraucht wird.

Allerdings, vor allem baut systemd selber auf dbus auf, weshalb mMn. gar nichts funktionieren dürfte ohne gestartetem dbus. (aus dem Grund lass ich auch die Finger von systemd...)
_________________
"der mac dennoch wesen geil"
Wolfram von Eschenbach, Parzival (Buch 1, Z. 7).
Ein frühes Statement gegen Windows.

My overlay
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1062
Location: Schweiz

PostPosted: Sat Oct 13, 2012 2:42 pm    Post subject: Reply with quote

Das mit dem displaymanager habe ich nun auch hinbekommen womit nun eigentlich alles da ist was ich zum Arbeiten normalerweise brauche.

Somit kann ich schon mal mein erstes Fazit abgeben zu systemd:
Es wird wohl einige Zeit brauchen um sich daran zu gewöhnen aber in Sachen Schnelligkeit wurden scheinbar keine leeren Versprechungen gemacht. Alles was ich jetzt noch sehe beim einschalten des Laptops ist das Lenovo Logo vom UEFI und 1 Sekunde später springt mir auch schon der KDM entgegen. 8O

franzf wrote:
Dann schau mal, wer diese ".service" files installiert (sollten in /usr/lib64/systemd/* liegen), und bau die Pakete neu - vielleicht geht es ja dann wie nach dem dbus-Neubau.
Quote:
Das grösste Problem hier dürfte wohl der dbus sein da dieser heutzutage ja von so ziemlich allem gebraucht wird.

Allerdings, vor allem baut systemd selber auf dbus auf, weshalb mMn. gar nichts funktionieren dürfte ohne gestartetem dbus. (aus dem Grund lass ich auch die Finger von systemd...)

Diese ".service"-Dateien die von "systemctl --all --full" als fehlerhaft aufgelistet werden existieren gar nicht. Plymouth habe ich nie installiert und werde ich auch nicht, keine Ahnung wieso diese auf der Liste auftauchen.
"display-manager.service" existiert in inzwischen aber auch nur wegen dem hier http://en.gentoo-wiki.com/wiki/Systemd#KDM.

EDIT:
Ich glaube ich weis jetzt wieso er auf der Liste nach nicht existierenden ".service"-Dateien schreit. Diese finden sich in anderen bereits existierenden ".service"-Dateien wie in dem vom KDM weiter oben.

EDIT2:
Jetzt ist es nur noch das:
Code:
UNIT                           LOAD   ACTIVE   SUB       JOB DESCRIPTION
auditd.service                 error  inactive dead          auditd.service
plymouth-quit-wait.service     error  inactive dead          plymouth-quit-wait.service
plymouth-quit.service          error  inactive dead          plymouth-quit.service
plymouth-start.service         error  inactive dead          plymouth-start.service

Da ich Plymouth nicht habe und auch nicht brauche ignoriere ich diese in Zukunft einfach aber das mit Audit muss ich noch genauer ansehen.

EDIT3:
Der Geist der rund alle 5 Sekunden lesend auf meine Festplatte zugegriffen hat scheint nun auch das weite gesucht zu haben, schon über eine Minute und der Systemmonitor vom KDE zeigt keinen Lesezugriff an.

EDIT4:
So mein kleiner Ausflug in die Welt von systemd ist nun nach fast zwei Tagen vorbei.

Schneller als OpenRC ist systemd auf jeden Fall und so weit ich das feststellen konnte funktioniert es auch genau so wie sollte. Unangenehm sind jedoch die Abhängigkeiten wie zum Beispiel dbus aber da eben selbiger sowieso bei den meisten installiert sein dürfte ist das wohl kaum so tragisch. Und das systemd mit seinem Journal auch gleich das syslog an sich reist ist wohl Geschmacksache funktioniert aber ebenfalls genau so wie es wohl gedacht ist. Schön ist das hier das jedem aufgezwungene consolekit weiterentwickelt wird und das es weder die Leistungsfähigkeit von systemd noch vom Rest negativ beeinflusst.

Am Ende muss ich sagen das ich mit systemd leben könnte aber aufgrund mangelnder Unterstützung seitens der ebuild-Schreiber oder Devs der Softwarepakete ist es im Moment unter Gentoo kein brauchbares init.
_________________
Mich braucht jeder. Zumindest behaupten viele, ich hätte gerade noch gefehlt. ;)
GPG: 0x54A19454 - Download | (0x5E2B12A0 ist veraltet)
Back to top
View user's profile Send private message
franzf
Advocate
Advocate


Joined: 29 Mar 2005
Posts: 3983
Location: Irgendwo im Nirgendwo

PostPosted: Sat Apr 13, 2013 10:39 am    Post subject: Reply with quote

schmidicom wrote:
Am Ende muss ich sagen das ich mit systemd leben könnte aber aufgrund mangelnder Unterstützung seitens der ebuild-Schreiber oder Devs der Softwarepakete ist es im Moment unter Gentoo kein brauchbares init.

Und genau das darf ich gerade erleben.
Hintergrund: https://bugs.gentoo.org/show_bug.cgi?id=463172
Es ist übel wenn man dem schlafenden Laptop den Stecker zieht und der nach dem Resume immer noch das "AC" Profil verwendet, obwohl mittlerweile auf Battery (fängt bei der Bildschirmhelligkeit an und endet beim ausbleibenden automatischen suspend)

Bei meinem letzten Versuch mit systemd gingen die alten initscripts noch - net, ssh etc. wurden automatisch gestartet. Diesmal: Nix!
Code:
# /etc/init.d/net.net0 start
 * WARNING: net.net0 is already starting

Ich musste einen anderen Rechner bemühen um herauszufinden, wie ich das Problem löse. Dazu hab ich ersmal schauen müssen, wie ich manuell per ifconfig + route mein Netzwerk aktiviere (hab ich mich nie drum geschert - Gentoo Doku, config anpassen -> Netzwerk mit static IP steht).
Jetzt hab ich Netzwerk aber immer noch kein sshd - dafür muss ich natürlich einen eigenen service schreiben, schauen wie man sshd startet usw.
pm-utils laufen nicht (k.A. wie und ob und vllt. gibts ja auch Konflikt mit systemd - das kümmert sich nämlich schon teilweise um PM-Sachen...) Einen service geschrieben, der mir "/sbin/hdparm -B 255 /dev/sda" ausführt damit meine hdd nicht so schnell kaputt geht... (wichtig: ExecStart erwartet absolute Pfadangaben, bei relativen Pfaden sagt er nur "Service erwartet ExecStart - und das fehlt hier!" - irreführende Meldung, 6, setzen...) Funktionieren tut es aber nur nach "Suspend" (Ich hätte ehrlich gesagt ein resume.target erwartet und nicht ein "After=suspend.target" - unintuitiv); nach dem Systemstart geht's nicht - aber da macht scheinbar systemd selber was, denn standardmäßig stellt sich die Platte auf "-B 128", nach dem Systemstart sagt es "254", ich will "255".

Nächstes Problem "Customization". Mit initscripten hat man immer schöne configs. Passen einem die Defaults nicht, ändert man die configs. In systemd muss man jetzt das anzupassende service-file von /usr/lib/systemd nach /etc/systemd kopieren und anpassen. Toll... Wenn sich das system-service-file ändert darf ich jetzt mit diff schauen wo (falls ich die Änderung überhaupt mitbekomme) und die Änderungen übertragen.

Größtes Problem: Abhängigkeiten.
Ich muss mir überlegen was mein service alles braucht. Noch schlimmer: ohne passender Anweisung in [Install] lässt er sich gar nicht aktivieren. Und an dem Punkt versteh ich auch die Doku nicht mehr :/ Ich kann mir z.B. irgend einen Fantasie-Alias überlegen, den angeben und mein service startet. Ist das sauber? k.A., ich denke nicht.
Bei network ist es klar (Alias=network.target) was mach ich aber mit ssh? Alias "telnet" ausdenken? Mein service "openssh.service" nennen und nach "ssh" aliasen? WantedBy/RequiredBy/Also machen einfach keinen Sinn, ICH bin es der das Ding braucht, kein anderer Service...

Und scheinbar ist die Fehleranalyse in [Unit]->After etc. ungenügend falls überhaupt vorhanden. Ich kann da reinschreiben was ich will, es gibt nicht mal ein warning, dass die Abhängigkeit nicht existiert. (So geschehen bei dem kleinen Schreibfehler für mein kdm.service)

Mit openrc musste ich mich einmal hinsetzen, Doku lesen, configs bearbeiten, rc-update add und alles lief. Evtl. beim etc-update nachgeschaut, wenn größere Änderungen anstanden. Jetzt muss ich zum init-Versteher mutieren. Ich muss (syntaktisch sicher einfachere) init-scripte schreiben. Mir über Abhängigkeiten Gedanken machen.
Das ist sicher zum großen Teil der mangelnden Unterstützung in Gentoo zu verdanken. Trotzdem wäre ein minimum an alltäglich benötigten services in einer vanilla-systemd-Installtion nicht schlecht. Oder braucht Poettering kein ssh? network kommt bei ihm sicher von NetworkManager, sollte aber nicht vorausgesetzt werden.

Ich würde systemd sofort wieder runterschmeißen! Aber ohne funktionierendem PM in kde komm ich aktuell nicht aus. Deshalb werde ich jetzt mit fehlender Funktionalität leben bis ich Zeit&Lust habe mich mit den fehlenden Sachen zu beschäftigen.

Danke, Lennart. Danke, KDE. Danke, Gentoo. Werden lustige und spannende Wochen...
_________________
"der mac dennoch wesen geil"
Wolfram von Eschenbach, Parzival (Buch 1, Z. 7).
Ein frühes Statement gegen Windows.

My overlay
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1062
Location: Schweiz

PostPosted: Sat Apr 13, 2013 11:03 am    Post subject: Reply with quote

Also bei mir werden Abhängigkeiten sauber aufgelöst, allerdings benutze ich auch keine initscripte aus openrc innerhalb von systemd. Und Netzwerkeinstellungen werden bei meinen Installationen tatsächlich mit dem networkmanager umgesetzt weil alles andere nicht oder nur mangelhaft funktionierte.

Aber mit all dem kann ich leben solange systemd auch wirklich schneller ist als das alte init.
_________________
Mich braucht jeder. Zumindest behaupten viele, ich hätte gerade noch gefehlt. ;)
GPG: 0x54A19454 - Download | (0x5E2B12A0 ist veraltet)
Back to top
View user's profile Send private message
franzf
Advocate
Advocate


Joined: 29 Mar 2005
Posts: 3983
Location: Irgendwo im Nirgendwo

PostPosted: Sat Apr 13, 2013 11:23 am    Post subject: Reply with quote

schmidicom wrote:
Aber mit all dem kann ich leben solange systemd auch wirklich schneller ist als das alte init.

Ist es hier nicht, bereits auf dem zweiten System (i3 SNB, ebenso auf dem i7 SNB)
Ich hab immer den Eindruck (jedenfalls liest es sich so) dass eine Umstellung auf SSD zum Anlass für eine Neuinstalation + Wechsel zu systemd genommen wird, und der schnellere Boot dann sysemd zugeschoben wird ;)

https://plus.google.com/u/0/107663298003289209275/posts/9XKaRKqsPY9
20 Sekunden von grub bis login. Auf ner SSD. Da bin ich hier gleich schnell (vllt. sogar schneller), mit HDD (5400rpm) + openrc - obwohl mein kernel unerklärlicherweise 9 Sekunden zum Starten braucht.
_________________
"der mac dennoch wesen geil"
Wolfram von Eschenbach, Parzival (Buch 1, Z. 7).
Ein frühes Statement gegen Windows.

My overlay
Back to top
View user's profile Send private message
Beelzebub_
Apprentice
Apprentice


Joined: 21 May 2012
Posts: 256
Location: outside/todesstern-2.01

PostPosted: Sun Apr 14, 2013 1:35 pm    Post subject: Reply with quote

franzf wrote:
schmidicom wrote:
Aber mit all dem kann ich leben solange systemd auch wirklich schneller ist als das alte init.



https://plus.google.com/u/0/107663298003289209275/posts/9XKaRKqsPY9
20 Sekunden von grub bis login. Auf ner SSD. Da bin ich hier gleich schnell (vllt. sogar schneller), mit HDD (5400rpm) + openrc - obwohl mein kernel unerklärlicherweise 9 Sekunden zum Starten braucht.


Haha das ist ja mal witzig:
Das Testsystem mit Systemd befindet sich auf einer virtuellen Maschine. Jedes OS bootet in einer VM viel schneller - habe die Erfahrung mit WindowsXP auf meiner VM gemacht - Also bietet die Demonstration eh keine vergleichs relevanten Ergebnisse. ;-)
_________________
Ich habe keine Angst vorm Sterben, ich habe nur Angst ich habe nicht genug gelebt.
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1062
Location: Schweiz

PostPosted: Mon Apr 15, 2013 9:15 am    Post subject: Reply with quote

franzf wrote:
Ich hab immer den Eindruck (jedenfalls liest es sich so) dass eine Umstellung auf SSD zum Anlass für eine Neuinstalation + Wechsel zu systemd genommen wird, und der schnellere Boot dann sysemd zugeschoben wird ;)

Auch wenn das in einigen Fällen den Tatsachen entsprechen mag ist es doch ziemlich dreist dies jedem zu unterstellen der eine solche Aussage macht...

Ich persönlich habe lange vor dem ausprobieren von systemd auf SSD umgestellt und war damals schon ziemlich genervt davon das selbst Windoof auf der SSD schneller startete als Gentoo mit OpenRC. Damals versuchte ich sogar über rc.conf (rc_parallel) OpenRC dazu zu bringen mehrere Dienste gleichzeitig zu starten damit es endlich mal etwas schneller geht doch das Ergebnis war das Gentoo meistens gar nicht mehr startete. Und als ob das hochfahren mit OpenRC nicht schon lange genug dauern würde, wird man beim abschalten gleich nochmal auf die Geduldsprobe gestellt. :evil:

EDIT:
Ich kann es kaum erwarten das ein offizielles baselayout erscheint welches openrc nicht mehr länger als Abhängigkeit drin hat.
_________________
Mich braucht jeder. Zumindest behaupten viele, ich hätte gerade noch gefehlt. ;)
GPG: 0x54A19454 - Download | (0x5E2B12A0 ist veraltet)


Last edited by schmidicom on Mon Apr 15, 2013 9:39 am; edited 1 time in total
Back to top
View user's profile Send private message
py-ro
Veteran
Veteran


Joined: 24 Sep 2002
Posts: 1521
Location: St. Wendel

PostPosted: Mon Apr 15, 2013 9:32 am    Post subject: Reply with quote

Und das die Systeme gefühlt in VMs schneller starten dürfte eher an den fehlenden BIOS Routinen liegen, Contorller initialisieren etc., das sparen die VMs sich.
Back to top
View user's profile Send private message
franzf
Advocate
Advocate


Joined: 29 Mar 2005
Posts: 3983
Location: Irgendwo im Nirgendwo

PostPosted: Mon Apr 15, 2013 11:28 am    Post subject: Reply with quote

@schmidicom:
Ich habe nicht behauptet dass es so wäre, sondern dass ich das Gefühl habe. Zusammen mit dem Smiley sollte es klar sein, dass die Aussage höchstens provokant gemeint war. Vor allem wollte ich meinen Frust abbauen...
Ich hab auch schon unterschiedliche Erfahrungen gehört. Manchen ging es so wie mir - kaum wahrnehmbare Steigerung, wenn überhaupt. Andere sprechen von Quantensprung. Liegt sicher an der Zahl der Dienste die man startet. network, ssh, cups, alsa, kdm. Keine Datenbanken oder sonstwas.

Mittlerweile geht übrigens alles. Ich schiebs auf den hohen Adrenalinspiegel... Wenn einem der nicht schlafen wollende (weil falsches Power-Profil) Laptop fast kurz vorm Blackout steht (alle Daten gespeichert - trotzdem geht da die Pumpe ganz schön), dann installiert man systemd, werkelt ewig rum und soll dann mal schnell was ausdrucken - und nix geht, während nach jedem boot/resume die Festplatte zum Klackern anfängt (nie wieder WD...) - puh ;)

Lösungen:
* stable openssh bringt ein systemd unit mit. Hab ich mich scheinbar vergreppt und die autocompletion hat nicht geklappt
* cups muss man sich aus testing ziehen.
* systemd-overlay bringt ein baselayout-systemd-2 mit, das NICHT openrc braucht.
Und jetzt läuft alles :)
_________________
"der mac dennoch wesen geil"
Wolfram von Eschenbach, Parzival (Buch 1, Z. 7).
Ein frühes Statement gegen Windows.

My overlay
Back to top
View user's profile Send private message
Erdie
Veteran
Veteran


Joined: 20 May 2004
Posts: 1727
Location: Heidelberg - Germany

PostPosted: Thu Apr 18, 2013 10:41 am    Post subject: Reply with quote

Also wenn mich KDE zukünftig zwingt eine zentrale Systemkomponente zu installieren, die keine Textbasierten logs schreibt, werde ich KDE auch auf meinem letzen Rechner durch XFCE ersetzen. Und das alles nur um eine paar Sekunden Zeit zu sparen? Lächerlich :(
_________________
Desktop AMD FX-4300 8GB RAM, Asus GF GTX 650. Sound RME Multiface + PCI + Cardbus, 2x RME Quadmic, 1x Behringer ADA8000.
2x IBM Thinkpad T60
Zotag Mag Mini Atom
Raspberry Pi
Back to top
View user's profile Send private message
firefly
Advocate
Advocate


Joined: 31 Oct 2002
Posts: 4123

PostPosted: Thu Apr 18, 2013 3:56 pm    Post subject: Reply with quote

Erdie wrote:
Also wenn mich KDE zukünftig zwingt eine zentrale Systemkomponente zu installieren, die keine Textbasierten logs schreibt, werde ich KDE auch auf meinem letzen Rechner durch XFCE ersetzen. Und das alles nur um eine paar Sekunden Zeit zu sparen? Lächerlich :(

Moment, bis jetzt ist AFAIK das "journal" von systemd nicht pflicht sondern eine optionale Komponente.
Und scheinbar lässt es sich auch deaktivieren (aktuell nur das logging an sich aber nicht den service, soll aber auf der TODO für journal stehen)
Reference:
https://bbs.archlinux.org/viewtopic.php?id=149884
http://lists.freedesktop.org/archives/systemd-devel/2012-March/004773.html
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn.
Back to top
View user's profile Send private message
franzf
Advocate
Advocate


Joined: 29 Mar 2005
Posts: 3983
Location: Irgendwo im Nirgendwo

PostPosted: Fri Apr 19, 2013 8:41 am    Post subject: Reply with quote

KDE hat mich nicht gezwungen, systemd zu verwenden. Das ist "nur" ein bug der sicher gefixt werden kann.
Ich hab mir den Code kurz angeschaut und für mich entschieden, dass der switch zu systemd weniger aufwändig ist (was vllt. am Ende doch eine Fehleinschätzung war...).
Was passieren kann ist dass consolekit durch systemd-login ersetzt wird (gnome-3.8 hat nur noch Unterstützung für systemd/logind). Das soll aber auch ohne systemd als init funktionieren. (Da bin ich gespannt wie lange das gültig bleibt)
Übrigens bist du auch mit xfce oder lxde vor solchen Problemen nicht sicher, da systemd mittlerweile zu weit verbreitet ist und viele Entwickler nicht mehr schauen ob es ohne systemd auch noch geht. (so wird es jedenfalls bei meinem Problem sein :()
_________________
"der mac dennoch wesen geil"
Wolfram von Eschenbach, Parzival (Buch 1, Z. 7).
Ein frühes Statement gegen Windows.

My overlay
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1062
Location: Schweiz

PostPosted: Fri Apr 19, 2013 9:58 am    Post subject: Reply with quote

Hätten die Devs vom alten init nicht geschlafen und währen auf die Bedürfnisse der DE's eingegangen wäre systemd nie so weit gekommen. Haben sie aber nicht, also ist ein anderer in die Bresche gesprungen. Und auch wenn dessen Umsetzung an einigen stellen "fragwürdig" ist so ist es dennoch nicht seine Schuld das andere seine Software als zwingende Abhängigkeit einsetzen.

Jetzt heißt es eben, überspitzt gesagt: Friss oder stirb!
_________________
Mich braucht jeder. Zumindest behaupten viele, ich hätte gerade noch gefehlt. ;)
GPG: 0x54A19454 - Download | (0x5E2B12A0 ist veraltet)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Diskussionsforum All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 2 of 6

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum