SiD
Nach allem was ich hier so mitbekommen habe wohl wegen dem geplanten Wechsel zu systemd
fs4000
Der ist noch nicht sicher, es wird lediglich die Kompatibilität hergestellt.
linux-ka
Es ist also nicht bindend ? Solange es nur eine parallel laufende Konfigurationsmöglichkeit darstellt, ist alles in Butter. Aber sollte man wirklich anfangen das System zu zerfasern, wäre es eine riesen Schande...
Creshal
Derzeit nicht. Aber Arch hat halt nicht so viel Manpower (siehe Einstellung des GUI-Installers), wenn man dadurch Entwicklungszeit einsparen kann…
skull-y
Creshal schriebDerzeit nicht. Aber Arch hat halt nicht so viel Manpower (siehe Einstellung des GUI-Installers), wenn man dadurch Entwicklungszeit einsparen kann…
... dann kann man den Schritt verstehen, auch wenn er dem ein oder anderen nicht gefällt.
fs4000
Sollten wir dann auch Mkinitcpio einstampfen und einfach auf Dracut wechseln? Da bezahlt Red Hat die Entwickler.
maik
Moin,
systemd-Umstellung hin oder her, schleichend oder direkt, hiermit zusammenhängend oder nicht, aber ich nahm bisher stets an, dass genau diese Einfachheit, nämlich sein Basis-System über nur eine Datei - die rc.conf - zu konfigurieren, Arch Linux unter anderem ausmacht. An einige meiner Vorredner anknüpfend stelle auch mir die große Frage, warum sich hiervon abgewandt wird und die Konfigurationen nun wieder über 'zig verschiedene .conf-Dateien läuft oder laufen soll?!
zico
Da hätte man doch schon vor Monaten rebellieren müssen. Das Blacklisten von Modulen ist schon lange nicht mehr per rc.conf möglich und davon ausgehend finde ich die jetzige Konfiguration dahingehend konsequenter. Ich hätt zwar auch lieber alles an einem Platz aber wie ich es versteh sagt "bisher" noch keiner, dass die rc.conf wie sie bisher war irgendwann komplett ausgemustert wird. Im Moment funktioniert sich noch und wenn systemd nicht "Pflicht" wird, wird sie es möglicherweise auch weiterhin tun.
fs4000
Das Blacklisten von Modulen in der rc.conf war aber ziemliches Gefrickel und ist histrorisch so entstanden, da trauere ich wirklich nicht darum, sondern bin froh dass diese Modifikation weg ist. Wir haben damals udev gepatcht, dass es modprobe nicht mehr direkt aufruft, sondern über ein Arch-spezifisches Wrapperskript, welches für jedes Modul die rc.conf geparst und alle Einträge im Modules-Array abgeklappert hat, ob nicht zufällig das Laden des Moduls verhindert werden soll. Das hat den Startvorgang teilweise schon einige Sekunden verlängert.
Ebenso ist das Einstellen der Zeitzone in der rc.conf nur ein Workaround, hier wird bei jedem Start überprüft, ob /etc/localtime noch auf die richtige Zeitzone zeigt. Früher wurde die Datei gleich jedes Mal komplett überschrieben.
Und ob die Hardwareuhr in UTC oder Locatime läuft, lässt man auch besser von hwclock verwalten, dann wird wenigstens auch bei manuellen Aufrufen die korrekte Einstellung verwendet.
yannsen
Hi,
ich habe meinen Laptop komplett neugemacht und habe nun auch keine rc.conf mehr weil ich komplett systemd einsetze. Ich finds schick, mal was neues! (Gute, technische Begründung, ich weiß)
Auch wenn ich mein init vermisse ;-)
Schön dass es "Vanilla"-systemd gibt und nicht ein ans System angepasstest. Ich beobachte die Entwicklung gespannt.
Könnte in Zukunf auch ein paar Probleme vermeiden bei Programmen die systemd kennen und sich nicht an dem "anderen" init-System von Archlinux verschlucken, z.B. vmware-tools etc.
Gruß yannsen
zico
Okay ich hatte auch schon früher immer nur den pc speaker blockiert aber - mehrere SEKUNDEN um einen Textstring zu durchsuchen? Wow.
Neja ich kann mich meinem Vorredner anschließen. Ich bin sehr gespannt, wie es weitergeht. 🙂
Creshal
zico schriebaber - mehrere SEKUNDEN um einen Textstring zu durchsuchen? Wow.
Für jedes geladene Modul ein Shellscript starten, das eine Datei öffnet, und dann in dem String was suchen… summiert sich halt. 😉
bubba
Hallo,
ich habe noch mal eine Verständnisfrage.
In meinem System wurde nach einem Update jetzt auch eine rc.conf.pacnew angelegt.
ALles ist auskommentiert bis auf die Daemons:
[em]
DAEMONS=(syslog-ng network crond)
[/em]
meine rc.conf sieht so aus:
[em]
DAEMONS=(syslog-ng crond acpid dbus networkmanager ntp cupsd cpufreq)
[/em]
Welche Datei ist denn nur relevant?
Muss ich jetzt den Daemon "network" in die rc.conf eintragen?
Laut WIKI soll man aber doch den Daemon network rausnehmen wenn man den networkmanager hat.
Ich blicke da leider nicht mehr so ganz durch.
fs4000
Relevant ist natürlich deine. Die neue kannst du erstmal ignorieren.
bubba
Kann ich die neue rc.conf.pacnew gefahrlos löschen?
fs4000
Kannst du tun, aber ich heb die Originalkonfiguration immer auf. Wenn du irgendwann auf das neue Konfigurationsschema umsteigen willst, könnts hilfreich sein.
bubba
OK, dankeschön.
Werde die rc.conf.pacnew besser nicht löschen.... sind ja eh nur 3,5 KB...bei einer 1TB HD werde ich das gerade noch verschmerzen können ;-)
mannohneschuh
bubba schriebOK, dankeschön.
Werde die rc.conf.pacnew besser nicht löschen.... sind ja eh nur 3,5 KB...bei einer 1TB HD werde ich das gerade noch verschmerzen können ;-)
Aber aufpassen das dir nicht die inodes ausgehen.