open-source greg schrieb@Ovion: Ich glaube nicht das Creshal so schnell lesen kann 😃
Deswegen mein Hinweis/meine Frage bzgl. des Loggers. 😉
open-source greg schriebIch sehe hinter der ganzen Lennyware keinen Sinn.
Wo du das gerade mal einwirfst, welchen Existenzzweck hat eigentlich PulseAudio? Ich nutze bei mir ALSA und ich wüsste nicht, was ich sonst noch haben wollen würde. Oder war das auch wieder sowas von der Sorte ALSA ist zu alt, wir brauchen was Neues (wobei PulseAudio ja meinen Recherchen nach auch ALSA benutzt)?
Ups, das mit dem logger hab ich doch glatt überlesen 😐

Pulseaudio soll angeblich dafür da sein mit mehreren Quellen gleichzeitig Sound ausgeben zu können. Mir kann das egal sein, da ich ein Soundkarte benutze die Hardwaremixing supported, für alle anderen geht das auch mit ein bischen Konfigurationsaufwand.
efreak4u schrieb@ fs4000
halt schaltet den Computer doch auch aus, oder haendelt systemd das anders?
Lies mal die Manpage, Systemd tut das einzig richtige: Anhalten und nicht ausschalten.
Creshal schrieb@Astorek:
>Was mir bei systemd auffällt: Die Zeit beim Herunterfahren (und auch Neustarten) ist extrem kurz. Kaum geklickt od. Befehl eingegeben, zwei Sekunden später ist der Rechner aus.
Jo. Was mir auch auffällt, ist eine Fehlermeldung kurz vor dem Runterfahren, die für eine Viertelsekunde aufflackert, bevor er sich ausschaltet. #fail
Sorry, ich musste einfach lachen als ich das las^^. Sowas ist natürlich ärgerlich... Ich hatte damit gottseidank noch nicht zu kämpfen...
open-source greg schriebPulseaudio soll angeblich dafür da sein mit mehreren Quellen gleichzeitig Sound ausgeben zu können. Mir kann das egal sein, da ich ein Soundkarte benutze die Hardwaremixing supported, für alle anderen geht das auch mit ein bischen Konfigurationsaufwand.
Wobei die Konfiguration auf dem Desktop über pavucontrol exzellent ist. Mal eben on-the-fly sämtliche Ein- und Ausgänge für jedes einzelne Programm umstellen und ggf. doppeln zu können, hat schon seine Vorzüge. Und wer das nicht braucht, freut sich immerhin out-of-the-box über die Möglichkeit, gleichzeitig einen Musikplayer und ein Youtube-Video laden zu können, ohne dass eines von beiden keinen Ton mehr ausspuckt^^...
Ovion schriebWenn ihr die Wahl hättet (neues System und so, wasauchimmer): Würdet du das (arch-)klassische SysVinit oder systemd nehmen?
Da ich mittlerweile die Konfiguration verstehe: Im Falle einer Neuinstallation eher systemd. Man muss zwar wissen, was wo konfiguriert wird, aber mit diesem Wissen ist es genauso schnell konfiguriert wie SysVinit. Auch, weil im Fall von Problemen das Initsystem einfach und schnell gewechselt werden kann^^.
@Astorek: Das wäre mit einem hübschen config Programm aber auch realisierbar. Man muss ja nicht das Rad neu erfinden, wenn man keine Lust hat den Reifen zu flicken 🙂

@Ovion: Warscheinlich würde (bzw. werde) ich keines vom beiden benutzen und mir eines der unzähligen anderen Init-Systeme für Arch einrichten.
Astorek schriebUnd wer das nicht braucht, freut sich immerhin out-of-the-box über die Möglichkeit, gleichzeitig einen Musikplayer und ein Youtube-Video laden zu können, ohne dass eines von beiden keinen Ton mehr ausspuckt^^...
Äh, unter welchen Umständen funktioniert das denn nicht? Bei mir läuft das zumindest out-of-the-box? oô
open-source greg schrieb Warscheinlich würde (bzw. werde) ich keines vom beiden benutzen und mir eines der unzähligen anderen Init-Systeme für Arch einrichten.
Aus den Repos oder aus dem AUR? In den Repos habe ich zumindest keine alternativen Systeme gefunden (was nix heißen muss).
Ich hatte damit auf meinem Laptop über ALSA immer Probleme und hatte keine Lust mich damit genauer zu befassen, geb ich zu^^. (Deswegen habe ich mit voller Absicht "out-of-the-box" geschrieben^^)
@Ovion: Im aur haben die noch nicht so ganz Fuß gefasst und in den Repos gibt es gar keine. Ein paar Beispiele wären: runit,launchd,cinit,einit,upstart,minit usw. .
Wenn es so viele Initsysteme gibt, ist systemd dann eigentlich das erste, was als Alternative zu SysVinit im "Mainstream" angekommen ist, weil es signifikant "besser" (was auch immer das heißt) ist als die anderen Alternativen oder weil es einfach verdammt aggressiv beworben wird?
Ovion schriebWenn es so viele Initsysteme gibt, ist systemd dann eigentlich das erste, was als Alternative zu SysVinit im "Mainstream" angekommen ist, weil es signifikant "besser" (was auch immer das heißt) ist als die anderen Alternativen oder weil es einfach verdammt aggressiv beworben wird?
Ja.
Ovion schriebWo du das gerade mal einwirfst, welchen Existenzzweck hat eigentlich PulseAudio? Ich nutze bei mir ALSA und ich wüsste nicht, was ich sonst noch haben wollen würde. Oder war das auch wieder sowas von der Sorte ALSA ist zu alt, wir brauchen was Neues (wobei PulseAudio ja meinen Recherchen nach auch ALSA benutzt)?
Bei Pulseaudio gibt es z. B. das Feature, dass man im Mixer einen Regler pro Anwendung hat. Das ist bisweilen ganz praktisch, man kann damit Anwendungen die Lautstärke abdrehen bzw. diese modifizieren, die das selber gar nicht unterstützen.

Zweites bisweilen ganz nützliches Feature ist, dass man Ausgabeströme relativ leicht auf andere Devices umleiten kann. Z. B. kann man einen Podcast, den man gerade am Rechner hört, mal eben auf den Bluetooth-UKW-Sender umleiten, um über das Küchenradio weiter zu hören.

Das alles ist nicht essentiell, aber manchmal nice-to-have.
Usul schriebBei Pulseaudio gibt es z. B. das Feature, dass man im Mixer einen Regler pro Anwendung hat. Das ist bisweilen ganz praktisch, man kann damit Anwendungen die Lautstärke abdrehen bzw. diese modifizieren, die das selber gar nicht unterstützen.
Es ist auch sinnvoll, wenn nicht jede Anwendung einzeln den Code für die Lautstärke enthalten muss, sondern diese Funktion zentral umgesetzt ist. Hier kann man den Code dann optimieren und alle profitieren davon. PA kann sogar, solange nur eine Anwendung läuft, das ganze Rumgerechne lassen und direkt die Soundkarte leiser drehen.

BTW: Systemd ist an Apples launchd angelehnt. Ich seh jetzt absolut keinen Vorteil darin, launchd statt systemd zu verwenden. Wurde das überhaupt portiert?
runiq schrieb
Ovion schriebWenn es so viele Initsysteme gibt, ist systemd dann eigentlich das erste, was als Alternative zu SysVinit im "Mainstream" angekommen ist, weil es signifikant "besser" (was auch immer das heißt) ist als die anderen Alternativen oder weil es einfach verdammt aggressiv beworben wird?
Ja.
Seufz. Ich liebe es, wenn man auf Ergänzungsfragen mit Ja/Nein antwortet... *rolleyes*

Was von beidem denn jetzt?
fs4000 schriebDas ist die neue rc.conf: http://projects.archlinux.org/initscripts.git/tree/rc.conf
Na, dann hat sich die Frage des Diskussionsstandes innerhalb der Devs ja selbst beantwortet… Zumindest für mich.
Also mir persönlich bricht da etwas wesentliches von Archlinux weg, da muß ich mich mit Alternativen zu sysvinit (eben nicht systemd) beschäftigen (oder den alten Stad mit udev 182 konservieren).

Irgendwelchen Installer oder glibc Kram steht da erstmal weit hinten an IMHO. Oder welches Unix-Deriverat hat nochmal eine "richtige" rc.conf.? ;-)
Also, nur damit ich das richtig verstehe:
der Hostname ist in /etc/hostname zu setzen,
der Zeichensatz in /etc/locale.conf,
die Keymap in /etc/vconsole.conf,
die Zeitzone in /etc/timezone,
die Daemons in /etc/rc.conf
Netcfg lässt sich, statt auch in der rc.conf, jetzt vermutlich gar nicht mehr so ohne weiteres konfigurieren
Dazu müssen noch irgendwo Kernelmodule verwaltet werden (wo eigentlich?) und die Optionen
USEDMRAID, USELVM, USEBTRFS bekommen auch neue Orte,

statt das alles in einer Datei zu erledigen.

Auf wieviele Konfigurationsdateien wird die rc.conf damit insgesamt zerlegt?

Und die rc.local gibt's auch nicht mehr.

EDIT:
fs4000 schriebDas ist die neue rc.conf: http://projects.archlinux.org/initscripts.git/tree/rc.conf

Für alle anderen Einstellungen werden die Systemd-Konfigurationsdateien empfohlen.
Nur für's Protokoll: Das gilt aber nur, wenn ich systemd benutze, oder?
Oh weh, ihr habt mich falsch verstanden. Es wird lediglich die Empfehlung ausgesprochen, die Konfiguration nach dem Systemd-Schema zu erstellen. In der rc.conf werden weiter alle Optionen verfügbar sein, nur müssen sie jetzt manuell aus der Manpage rausgesucht und hinzugefügt werden oder ihr übernehmt einfach, was ihr bereits habt.

Netcfg wird schon seit einiger Zeit über /etc/conf.d/netcfg konfiguriert, der Support für die rc.conf sollte eigentlich bereits aufgegeben werden. Da allerdings die Initskripte immer die rc.conf parsen, gibts das für Nicht-Systemd-User noch als Nebenprodukt.

Für Interessierte der aktuelle Stand der rc.conf Manpage: http://projects.archlinux.org/initscripts.git/tree/rc.conf.5.txt
Ok, das heißt, ich kann systemd benutzen und dabei meine bisherige rc.conf so weiterverwenden wie bisher. WENN ich also möchte, kann ich meine rc.conf auch filetieren, durch den Schredder jagen, anzünden und die staubigen Überreste nach systemd-Schema im System verteilen, muss ich aber nicht. Ich kann die komplette Konfiguration wie bisher auch in der rc.conf erledigen und stelle damit effektiv keinen Unterschied zum Arbeiten mit SysVinit fest (zumindest seitens der Konfiguration).

Korrekt so?

Wie sieht's mit der rc.local aus?

Ich halte aus Interesse dennoch mal die Frage aufrecht, auf wieviele configfiles sich die rc.conf verteilen würde, wenn man konsequenten systemd-Stil anwendet.
Ich weiß leider wirklich nicht, wie weit der rc.conf Support von systemd reicht. Angeblich ist er da, aber es wird davon abgeraten sich darauf zu verlassen und ich wollts auch nicht ausprobieren. Neu ist jetzt nur, dass auch für SysVinit/Initscripts das Systemd-Schema empfohlen wird, aber es wird keine Funktionalität weggenommen.

rc.local wird momentan nicht angetastet, aber selbst wenn, die Initskripte hätten andere Wege Befehle in den Bootvorgang einzuschleusen.

Ich zähle bis zu 7 Konfigurationsdateien/-ordner zusätzlich zur rc.conf (alles unter /etc):
hostname
hwclock (ist eigentlich weniger einer Konfigurationsdatei, das übernimmt jetzt aber die UTC/localtime Einstellung)
timezone
locale.conf
vconsole.conf
modprobe.d (das haben wir ja bereits fürs nicht mehr vorhandene Blacklisting oder sonstige Optionen)
modules-load.d

Im Prinzip gibts auch noch /etc/localtime, was weiterhin irgendwie so eine Zeitzonenenspezifikation sein muss. /etc/timezone ist auch nicht zwingend nötig, aber Gnome zeit dann nicht die richtige Zeitzone an.
fs4000 schriebNeu ist jetzt nur, dass auch für SysVinit/Initscripts das Systemd-Schema empfohlen wird, aber es wird keine Funktionalität weggenommen.
Also soll sich nicht systemd an Arch anpassen, sondern nach Möglichkeit soll sich Arch sogar ohne systemd an systemd anpassen?