Böse Zungen behaupten es sei vor allem ein Egostrip. Sehr Böse Zungen natürlich nur.
Im Ernst, es gibt durchaus Unterschiede, ob man wegen denen wirklich das aufkeimende Upstart angreifen muss, und damit am Ende ein noch größere Chaos produziert, ist fraglich. Ob es Vorteile sind, ist sowieso mehr als diskutabel. Du findest seine Meinung auf seinem Blog, http://0pointer.de/blog. Such dort einfach nach Upstart, da erklärt er die Unterschiede grob, und seine ideen.
habe gerade mal in den blog (http://0pointer.de/blog) reingeschaut. Klingt eigentlich alles sehr vernünftig was er da schreibt. Ich kann allerdings nicht beurteilen, in wie fern die angesprochenen Limitierungen von upstart so wirklich Gegenstand sind. Zumindest deckt es sich ansatzweise mit meinen Erfahrungen, was beispielsweise den Autostart von bestimmten Prozessen (konkret: mysqlserver ) angeht: Es scheint mir doch etwas umständlich, den Autostart mittels upstart an- bzw. abzuschalten. Das war mit update-rc.d irgendwie besser.
> Böse Zungen behaupten es sei vor allem ein Egostrip.
Von Red-Hat? Novell hat vor systemd zu übernehmen und hat die Integration von upstart vor einer Weile gecancelt. Damit werden die zwei großen Enterprise-Systeme damit laufen.
Q: If you love Apple launchd so much, why not adopt that? A: launchd is a great invention, but I am not convinced that it would fit well into Linux, nor that it is suitable for a system like Linux with its immense scalability and flexibility to numerous purposes and uses.
Hört sich für mich nach ziemlich unspezifischem und unbegründeten Gefasel an. Im Text steht dann noch, dass systemd besser mit unmodifizierten Daemons zurechtkommt als launchd.
Von Max Mustermann am Mi, 15. September 2010 um 18:19 #
Bei mit tut alsa bestens. Die Idee hinter PA ist eigentlich ne feine Sache. Aber nach endlosem Gefummel mit dem Zeug hab ich es endgültig abgeschrieben. Deshalb erlaube ich mir ein verhaltenes: who cares...
Von zettberlin am Mi, 15. September 2010 um 21:39 #
>PulseAudio ist doch schon fertig?
Ach ja? Ein System, das mit hunderten offenen Bugreports zu tun hat, das am laufenden Band Nutzer mit kaum lösbaren Problemen konfrontiert und für das es keine Endnutzerorientierte Einstellungsmögklichkeiten gibt ist also "schon fertig"?
Nur ein Beispiel: dutzende verschiedenen Audiokartenmodelle haben einen envy24-Chip an Bord. Audiophile von Hoontech, Gamerkarten von Terratec und Musikerkarten von MAudio. Foren und Mailinglisten laufen über mit verzweifelten Hilfeersuchen von Nutzern dieser Karten, weil PA nicht vernünftig mit dem Alsatreiber für envy/ICE1712 zusammenarbeitet. Die ICE1712/envy24 - Karten waren vor PA der Gold-Standard unter Linux. Noch besser ging nur mit RME Hammerfall.
Es sollte mindestens kein Problem sein, PA einfach auszuschalten, wenn es Stress macht. Aber selbst das funktioniert nicht sicher und nicht in jeder Distro. Von einem nachgeordneten System wie einem Soundserver darf gar nichts abhängen -- ohne PA funktionieren in vielen Distros aber auch Programme nicht, die Audio gar nicht zwingend benötigen.
Da gibt es noch sehr, sehr viel zu tun für Lennart Poettering.
Von zettberlin am Mi, 15. September 2010 um 23:07 #
> System -> Einstellungen -> Klang
Ich kann da irgendwie keinen Knopf "Soundserver anhalten" finden. Genauso wenig wie eine brauchbare Übersicht der angeschlossenen Clients oder eine Auswahl der installierten Sinks. Geschweige denn eine hübsche Oberfläche, mit der man das Routing bearbeiten könnte. All das sind Funktionen, die PA tatsächlich drauf haben könnte. Falls Du eine Distro kennst, die dergleichen anbietet, freue ich mich über den Tipp.
Nebenher: PCLinuxOS bietet in Drakconf immerhin die Option, PA zu verwenden oder nicht zu verwenden. Damit funktioniert eine envy24-Karte unter PCLinuxOS ootb auch mit mehreren Quellen. Solange PA nicht wenigstens so unauffällig funktioniert wie dmix, ist es nicht fertig sondern immer noch eine Regression.
Von zettberlin am Do, 16. September 2010 um 15:55 #
>...nichts was einen User was angeht
Alles, was einer von 100 Nutzern irgendwann mal tun will, geht alle Nutzer an.
Wenn ich darauf verzichten will, dem Nutzer die Möglichkeit zu geben, einen Serverprozess zu steuern, setze ich voraus, dass dieser Server *immer* unter allen Umständen tut, was der Nutzer von ihm will. Wer so etwas bei einem Soundsystem für Linux 2010 voraussetzt, ist bestenfalls inkompetent und gedankenlos.
Von anonymous am Fr, 17. September 2010 um 18:47 #
... endlich mal PA sauber hinbekommen!
Besonders Fedora macht bei PA am meisten Probleme! Dieses A*loch hat mir schon Stunden gekostet. Was schreib denn um den Brei herum: Er ist ein Arschloch!
Ach, der Autor von systemd ist auch der von PulseAudio? Und dieses Pulse Audio wurde von fast allen Distributionen als wichtige Systemkomponente in ihren Gnome-Ausführungen übernommen, obwohl es außer den Entwickler nicht genug Manpower dahinter gibt? Das ist extrem dumm.
Dementsprechend sollte man sich das mit systemd nochmal überlegen. Viele Vorteile gegenüber upstart soll es ja nicht haben und dafür ein zweites PulseAudio zu riskieren, ist schon sehr gewagt. upstart funktioniert jedenfalls ohne Probleme und wird verantwortungsvoll entwickelt.
Ach, der Autor von systemd ist auch der von PulseAudio? Und dieses Pulse Audio wurde von fast allen Distributionen als wichtige Systemkomponente in ihren Gnome-Ausführungen übernommen, obwohl es außer den Entwickler nicht genug Manpower dahinter gibt? Das ist extrem dumm.
Dementsprechend sollte man sich das mit systemd nochmal überlegen. Viele Vorteile gegenüber upstart soll es ja nicht haben und dafür ein zweites PulseAudio zu riskieren, ist schon sehr gewagt. upstart funktioniert jedenfalls ohne Probleme und wird verantwortungsvoll entwickelt.
Innerhalb von Fedora geht das soweit, daß F14 bislang die alten Pulse Audio Pakete von F13 enthält (durch Vererbung) und es seit dem Frühjahr auch keine Updates für F13 oder F12 gegeben hat. Bugs und Unzulänglichkeiten zu beheben gäbe es genug. Allerdings auch eine breite Userbasis, die nicht oder nicht schwer genug betroffen ist, um es als großes Ärgernis anzusehen bzw. um auf Knopfdruck Investitionen in Pulse Audio zu tätigen. Ist ja nicht trivial, mal eben rückwirkend (mehrere Monate!) in die (Weiter-)Entwicklung und Fehlerbehebung einzuspringen.
Was sind denn die Vorteile gegenüber upstart?
Böse Zungen behaupten es sei vor allem ein Egostrip. Sehr Böse Zungen natürlich nur.
Im Ernst, es gibt durchaus Unterschiede, ob man wegen denen wirklich das aufkeimende Upstart angreifen muss, und damit am Ende ein noch größere Chaos produziert, ist fraglich. Ob es Vorteile sind, ist sowieso mehr als diskutabel.
Du findest seine Meinung auf seinem Blog, http://0pointer.de/blog. Such dort einfach nach Upstart, da erklärt er die Unterschiede grob, und seine ideen.
habe gerade mal in den blog (http://0pointer.de/blog) reingeschaut.
Klingt eigentlich alles sehr vernünftig was er da schreibt. Ich kann allerdings nicht beurteilen, in wie fern die angesprochenen Limitierungen von upstart so wirklich Gegenstand sind.
Zumindest deckt es sich ansatzweise mit meinen Erfahrungen, was beispielsweise den Autostart von bestimmten Prozessen (konkret: mysqlserver ) angeht: Es scheint mir doch etwas umständlich, den Autostart mittels upstart an- bzw. abzuschalten.
Das war mit update-rc.d irgendwie besser.
Bei SysV musstest du dafür 2 Symlinks entfernen, bei upstart eine Zeile ändern. Beides vernachlässigbar geringer Aufwand.
> Böse Zungen behaupten es sei vor allem ein Egostrip.
Von Red-Hat? Novell hat vor systemd zu übernehmen und hat die Integration von upstart vor einer Weile gecancelt.
Damit werden die zwei großen Enterprise-Systeme damit laufen.
Es gibt ein Interview mit dem systemd-Entwickler bei den Linux Outlaws, Episode 160, ab 1:04:50, wo das beantwortet wird.
(vorher wird noch über PulseAudio geredet)
Die Interessantere Frage wäre: Was ist der Vorteil gegenüber launchd?
Poettering schreibt dazu: http://0pointer.de/blog/projects/systemd.html
Q: If you love Apple launchd so much, why not adopt that?
A: launchd is a great invention, but I am not convinced that it would fit well into Linux, nor that it is suitable for a system like Linux with its immense scalability and flexibility to numerous purposes and uses.
Hört sich für mich nach ziemlich unspezifischem und unbegründeten Gefasel an. Im Text steht dann noch, dass systemd besser mit unmodifizierten Daemons zurechtkommt als launchd.
... denn nun dürfen wir wieder hoffen, dass Pulse Audio doch nicht erst in ein paar Jahren richtig fertig wird....
Bei mit tut alsa bestens. Die Idee hinter PA ist eigentlich ne feine Sache. Aber nach endlosem Gefummel mit dem Zeug hab ich es endgültig abgeschrieben. Deshalb erlaube ich mir ein verhaltenes: who cares...
PulseAudio ist doch schon fertig? Was für eine Distro hast du denn, dass das da nicht geht?
>PulseAudio ist doch schon fertig?
Ach ja? Ein System, das mit hunderten offenen Bugreports zu tun hat, das am laufenden Band Nutzer mit kaum lösbaren Problemen konfrontiert und für das es keine Endnutzerorientierte Einstellungsmögklichkeiten gibt ist also "schon fertig"?
Nur ein Beispiel: dutzende verschiedenen Audiokartenmodelle haben einen envy24-Chip an Bord. Audiophile von Hoontech, Gamerkarten von Terratec und Musikerkarten von MAudio. Foren und Mailinglisten laufen über mit verzweifelten Hilfeersuchen von Nutzern dieser Karten, weil PA nicht vernünftig mit dem Alsatreiber für envy/ICE1712 zusammenarbeitet.
Die ICE1712/envy24 - Karten waren vor PA der Gold-Standard unter Linux. Noch besser ging nur mit RME Hammerfall.
Es sollte mindestens kein Problem sein, PA einfach auszuschalten, wenn es Stress macht. Aber selbst das funktioniert nicht sicher und nicht in jeder Distro. Von einem nachgeordneten System wie einem Soundserver darf gar nichts abhängen -- ohne PA funktionieren in vielen Distros aber auch Programme nicht, die Audio gar nicht zwingend benötigen.
Da gibt es noch sehr, sehr viel zu tun für Lennart Poettering.
Huh? "System -> Einstellungen -> Klang" oder "Lautstärke-Indicator -> Audio-Einstellungen ..."
> System -> Einstellungen -> Klang
Ich kann da irgendwie keinen Knopf "Soundserver anhalten" finden. Genauso wenig wie eine brauchbare Übersicht der angeschlossenen Clients oder eine Auswahl der installierten Sinks. Geschweige denn eine hübsche Oberfläche, mit der man das Routing bearbeiten könnte.
All das sind Funktionen, die PA tatsächlich drauf haben könnte. Falls Du eine Distro kennst, die dergleichen anbietet, freue ich mich über den Tipp.
Nebenher: PCLinuxOS bietet in Drakconf immerhin die Option, PA zu verwenden oder nicht zu verwenden. Damit funktioniert eine envy24-Karte unter PCLinuxOS ootb auch mit mehreren Quellen.
Solange PA nicht wenigstens so unauffällig funktioniert wie dmix, ist es nicht fertig sondern immer noch eine Regression.
"Soundserver anhalten" ist doch nichts was einen User was angeht.
Im Grunde natürlich nicht, allerdings würde es vorrausetzen das Pulseaudio wirklich 100%ig stabil ist. Und leider ist es das nicht :/
>...nichts was einen User was angeht
Alles, was einer von 100 Nutzern irgendwann mal tun will, geht alle Nutzer an.
Wenn ich darauf verzichten will, dem Nutzer die Möglichkeit zu geben, einen Serverprozess zu steuern, setze ich voraus, dass dieser Server *immer* unter allen Umständen tut, was der Nutzer von ihm will. Wer so etwas bei einem Soundsystem für Linux 2010 voraussetzt, ist bestenfalls inkompetent und gedankenlos.
... endlich mal PA sauber hinbekommen!
Besonders Fedora macht bei PA am meisten Probleme! Dieses A*loch hat mir schon Stunden gekostet. Was schreib denn um den Brei herum: Er ist ein Arschloch!
Leider ist der Autor derart intensiv mit systemd beschäftigt, daß Pulse Audio innerhalb der Fedora Distribution seit Monaten nicht betreut wird:
* bug Liste
* package Liste
Ach, der Autor von systemd ist auch der von PulseAudio? Und dieses Pulse Audio wurde von fast allen Distributionen als wichtige Systemkomponente in ihren Gnome-Ausführungen übernommen, obwohl es außer den Entwickler nicht genug Manpower dahinter gibt? Das ist extrem dumm.
Dementsprechend sollte man sich das mit systemd nochmal überlegen. Viele Vorteile gegenüber upstart soll es ja nicht haben und dafür ein zweites PulseAudio zu riskieren, ist schon sehr gewagt. upstart funktioniert jedenfalls ohne Probleme und wird verantwortungsvoll entwickelt.
Ach, der Autor von systemd ist auch der von PulseAudio? Und dieses Pulse Audio wurde von fast allen Distributionen als wichtige Systemkomponente in ihren Gnome-Ausführungen übernommen, obwohl es außer den Entwickler nicht genug Manpower dahinter gibt? Das ist extrem dumm.
Dementsprechend sollte man sich das mit systemd nochmal überlegen. Viele Vorteile gegenüber upstart soll es ja nicht haben und dafür ein zweites PulseAudio zu riskieren, ist schon sehr gewagt. upstart funktioniert jedenfalls ohne Probleme und wird verantwortungsvoll entwickelt.
http://pulseaudio.org/wiki/Community#People nennt einen weiteren Entwickler, und
unter http://git.0pointer.de/?p=pulseaudio.git findet sich auch Aktivität (deren Ausmaß ich nicht beurteilen kann), ein Release hat es aber seit Nov 2009 nicht gegeben.
Innerhalb von Fedora geht das soweit, daß F14 bislang die alten Pulse Audio Pakete von F13 enthält (durch Vererbung) und es seit dem Frühjahr auch keine Updates für F13 oder F12 gegeben hat. Bugs und Unzulänglichkeiten zu beheben gäbe es genug. Allerdings auch eine breite Userbasis, die nicht oder nicht schwer genug betroffen ist, um es als großes Ärgernis anzusehen bzw. um auf Knopfdruck Investitionen in Pulse Audio zu tätigen. Ist ja nicht trivial, mal eben rückwirkend (mehrere Monate!) in die (Weiter-)Entwicklung und Fehlerbehebung einzuspringen.