Lies den mit Argumenten gespickten Originalartikel, die Sessionmanager und das Initsystem mit deiner Daemon-Überwachung machen weitestgehend dasselbe. Warum sollte man die Funktionen nicht in einer gemeinsamen Codebasis zusammenführen?
Eierlegende Wollmilchsau ist die negative Annäherung an den Ansatz, Entrümpelung redundanter Dienste und Verschlankung der Systemprozesse klingt doch viel schöner. Wir werden sehen.
Es ist trotzdem vollkommen unrealistisch das KDE und GNOME diese System verwenden werden, weil beide DEs auch auf vielen anderen Plattformen und nicht nur Linux laufen.
Weder Gnome, noch KDE werden diesen Dienst explizit benutzen müssen. Sobald eine Destopumgebung läuft, ist die Funktionalität von systemd mindestens einmal abstrahiert.
Oder anders gesagt: Gnome und KDE bekommen gar nicht mit, dass irgendwo weiter unten systemd läuft.
The problem set of a session manager and an init system are very similar: quick start-up is essential and babysitting processes the focus. Using the same code for both uses hence suggests itself. Apple recognized that and does just that with launchd. And so should we: socket and bus based activation and parallelization is something session services and system services can benefit from equally.
Klingt spannend und auch der Originalartikel erweckt den Eindruck, dass hier jemand die Sache basierend auf den Erfahrungen und Designsünden vergangener Jahrzehnte nochmal grundlegend aufgebaut hat. Dabei hat er auch über den Tellerrand geschaut und sich von Lösungen inspirieren lassen, die auf anderen Systemen überzeugen konnten.
Ich hoffe, es springen jetzt weitere Entwickler, vielleicht ein paar seiner Red Hat Kollegen, auf und der Dienst schafft es für erste Feldtests und Weiterentwicklungen schnell nach Fedora.
Ich ärgere mich darüber, wie schlecht eigentlich der Bootprozess bisher mit initd abläuft, obwohl ein bisschen Graphentheorie ausreicht, um was besseres zu erzeugen, um es zu beschleunigen.
Ich bin Informatiker und entwickle Software und leider verkennen viele die Möglichkeiten der Systematisierung und Parallelisierung. "Der Verwaltungsaufwand ist zu groß." oder "Das versteht doch keiner." höre ich immer wieder. Wie ein Compiler funktioniert, wissen viele auch nicht und trotzdem wird's verwendet, inklusive der vielen vorgefertigten Frameworks.
Und die ganzen Optimierungen die ein Kompiler durchführt sind i.d.R. komplexer als das auflösen von Dienst-Abhängigkeiten, würde ich schätzen. (Kann ja sein das ich dabei was übersehe.)
Ja du übersiehst was, das Auflösen von Abhängigkeiten reicht ja hier nicht. Das schwierige ist, dass es hier nicht nur um statische Zustände geht 0,1 an aus. Sondern es geht z.B. um die Frage was tun, wenn ein abhängiger Dienst nicht startet oder verzögert etc. das sind die Herausforderungen.
In solchen Projekten entscheidet nicht ein einziger, wie etwas abläuft. Aber seien wir ehrlich: Der init-Vorgang sieht aus wie ein großer Hack und damit Dienste in der richtigen Reihenfolge gestartet werden, müssen sie durchnummeriert werden. Ich musste auch feststellen, dass run-parts keine Dateien akzeptiert, die auf .sh enden. Man schleppt historische Altlasten mit sich, was einerseits sehr interessant ist, Programme laufen zu haben, die sich seit zehn Jahren nicht mehr geändert haben, aber andererseits wird es den Nutzer schwer gemacht, weil viele Werkzeuge sich seltsam verhalte, wie z. B. run-parts.
Schwierig am init-d Prozess sind wohl die Seiteneffekte. Ich weiß jetzt nicht, wie weit der im Regelfall alles konfiguriert und inwieweit andere Anwendungen init.d konsultieren. Sehr beleibt: Schauen, ob eine Datei im Init.d-Order existiert und davon das Verhalten abhängig machen. Das macht die Sache kompilziert.
Beruflich hatte ich auch mit so einem Init-Ding zu tun, der für das firmeneigenen Framework entwickelt wurde und für die Kernanwendung mehrere Prozesse startet. Die haben auch wieder den Unsinn mit den Zahlen gemacht: Hauptsache, es ist richtig durchnummeriert. Dabei müsste man nur Abhängigkeiten modellieren, topologisch sortieren und das Ding ist fertig, robust und der Verwaltungsaufwand ist minimal. Es wird verkannt, wieviel Zeit so Konfigurationsdinge mit sich bringen. Selbst Leute unterschätzen es, die es eigentlich besser wissen müssten, weil sie über Programmiererfahrung verfügen.
Ich frage mich, wie groß der Bedarf daran ist dynamisch Deamon-Abhängigkeiten aufzulösen. Ich muss dazu sagen, dass ich kein erfahrener Linux-Admin bin und vielleicht fehlt mir dazu einfach die nötige Praxis. Aber wie viele Deamonen gibt es denn so? 10, 20? Ich bin der Meinung derartige Abhängigkeiten einmal bei der Produktion einer Distribution zu berücksichtigen ist doch wirklich kein Problem. Dann kann man das doch auch parallell starten lassen, was sich parallel starten lässt. Bei Arch funktioniert das auch.
Ansonsten klingt systemd ja ganz gut. Aber ein Sessionmanager finde ich da deplaziert. Wenn KDM und GDM die gleiche Funktion erfüllen, wäre es meiner Meinung eher an Freedesktop.org da mal etwas zu tun.
Abgesehen davon, hätte man sich vielleicht mal mit Upstart-Entwickler kurzschließen können. Jetzt zwei Dienste zu entwickeln, die zu einem großen Teil die gleiche Funktionen haben soll, finde ich auch mehr als unglücklich.
Ja, also bei mir auf dem Server laufen genau 15 Services.
Auf den Clients sind es aber deutlich weniger, ca. 5.
Upstart kannst du uebrigens nicht mit systemd vergleichen, da die grundlegenden Konzepte ganz andere sind. Das faengt ja schon bei der Programmiersprache an.
Es geht ja nicht um Server, sondern Desktopsysteme. Wen stört die Startgeschwindigkeit bei Servern? Niemand. Die Startet man ja nicht täglich sondern vielleicht alle 100 Tage mal...
Dieser Spa*ti hat ein funktionierendes AudioSystem zerstört, daß vorher einfach funktionierte. Scheinbar ist es langweilig und out, wenn mal etwas funktioniert.
Seitdem PulseAudio in den üblichen Distributionen Einzug hielt und ständig Probleme bereitete, durfte ich bei Fedora, Ubuntu, Suse & Co ständig am PulseAudio rumfrickeln, bis ich dann entnervt komplett Slackware verwendete.
Wenn man in seinem Blog so seine Kommentare liest, hat der echt nen Knall: immer sind alle anderen (Hardware, Treiber, Distributor, Programm) Schuld, nur er nicht. Mit den Stunden, in denen ich mich mit PulseAudio geärgert habe, ist er ein rotes Tuch geworden.
Und jetzt möchte dieser Typ etwas programmieren, was PID 1 besetzt? Gehts noch??? Diese Distribution(en) werde ich NEVER EVER, NIE NIE einsetzen. Vorher wechsle ich noch zu FreeBSD.
Red Hat hat leider noch mehr Leute von der Sorte auf der Gehaltsliste, und dummerweise an zentralen Stellen wie X.Org oder Audio. David Airlie hat sich ja auch gerade erst wieder beliebt gemacht.
Das führt dann am Ende zu Distributionen wie Fedora, der Messlatte für Stabilität.
> > Dreppersyndrom. > Red Hat hat leider noch mehr Leute von > der Sorte auf der Gehaltsliste
Nein, RedHat hat GOTT SEI DANK solche Leute auf der Gehaltsliste.
Kann es sein dass du einfach nicht die Qualifikation hast zu begreifen was genau diese Leute in den letzten Jahren geleistet haben?
> und dummerweise an zentralen Stellen > wie X.Org oder Audio.
Und dem Kernel und Apache und so weiter Schau dir doch mal alleine beim httpd an welche Domain hinter den meisten Security-Fixes der letzten Jahre steht
Und Nein das heisst bei Gott nicht dass der gleiche die Lücke rein gemacht hat
> David Airlie hat sich ja auch gerade erst > wieder beliebt gemacht.
Ein guter Techniker hat es nicht nötig sich beliebt zu machen. Langfristige Entscheidungen treffen die auch mal weh tun beisst sich mit beliebt machen, nur mit Leuten die beliebt sein wollen bricht das ganze aber mittelfristig zusammen weil es irgendwann zu spät ist grundlegende Änderungen zu machen und ab dann bringt es plötzlich keinem was wenn 10 Jahre alle nett und beliebt waren.
Dann heisst es plötzlich "Na hätten sie doch" und "Woher hätte ich wissen sollen" - Genau deswegen sollten manche Dauerkritiker sich mal Fragen ob sie in ihrem Leben auch nur ansatzweise solche Leistungen gebracht haben und überhaupt in der Lage sind etwas so weit zu verstehen um es kritisieren zu können.
> Das führt dann am Ende zu Distributionen > wie Fedora, der Messlatte für Stabilität.
Wo genau ist dein Problem mit Fedora? Wenn du sofort nach Release ein Dist-Upgrade machst kann da kein Mensch was dafür ausser Du selbst.
Kann man machen wenn man mit dem System wirklich umgehen kann und auch etwas Spass am Basteln hat - Mache ich seit Jahren auf meiner Arbeitsmaschine.
Auf den Servern läuft immer Dist-1 und kurz vor Ablauf des Supports von F11 kommt F12 drauf. Wenn man zu dumm ist das zu handhaben muss man halt ein RHEL/CentOS nehmen, darf dann aber auch nicht rumflennen wenn ein Paket zu alt ist
> Argumentum ad hominem. > Ich denke nicht dass es Sinn macht auf > der Ebene weiter zu diskutieren.
Schön für dich dass du in der Lage bist eine paar Sätze die dir nicht passen aus dem Kontext zu reissen und dich daann wie ein kleines Kind in die Ecke zu stellen und "so nicht" zu schreien
95% der Argumente hast du einfach locker ignoriert weil du dazu entweder mangels Hintergrundissen nichts sagen kannst (OK das müsste man dir dann hoch anrechnen) oder nicht willst weil du nicht dazu stehen willst es dir mit Kritik halt einfach zu machen.
> Stimmt doch. Er ist halt ein Genie! Unable to fail, Dreppersyndrom. Der Vergleich hinkt. Drepper ist halt wirklich begabt. Mangelnde Diskussionsbereitschaft kann man ihm (Drepper) eigentlich auch nich vorwerfen, er engagiert sich ja auch jenseits von Redhat z.B. in Opengroup-Gremien.
Ja, PulseAudio hat auch bei mir das Soundsystem für lange Zeit zurück in die 90er verfrachtet. Jetzt funktionierts wieder so allmählich. Ab und zu hab ich noch Hacker, e.g. wenn ich Musik pausiere und dann stoppe o.ä., aber im Großen und ganzen gehts jetzt wieder. Hat ja lange gedauert. Aber warum an etwas das eh hervorragend funktioniert hat so herumgepfuscht werden musste versteh ich auch nicht. Ein/zwei Distri Releases lang war Sound unter Linux einfach nur Horror. Mit fast Sekundenlange Latnecy. Spiel so mal ein Spiel! Das macht echt keinen Spaß. Das man eine Sekunde warten muss wenn man play/pause in einen Audioplayer drückt ist da ja noch fast verschmerzbar. Und sagt nicht es liegt an Hardware/Treiber/Programmen, denn alles das hat früher mit reinem ALSA bzw. Windows auf der selben Hardware (und mit den selben Programmen) vollkommen einwandfrei funktioniert.
Dieser Spa*ti hat ein funktionierendes AudioSystem zerstört, daß vorher einfach funktionierte.
Haha! Selten so einen gute Witz gehört. Das System funktionierte so gut, dass Arts, ESD, Jack und wie sie alle heissen eigentlich nur so aus Scherz gemacht wurden. Schliesslich funktionierte das System so gut...
Endlich hat sich jemand diesem Haufen Müll angenommen und mit PA etwas erstellt, was auch mit Windows und Mac konkurrieren konnte. Zuvor war Linux auf diesem Sektor in der Steinzeit. Gott sei dank hat sich es nun geändert.
Im Übrigen... Da du ja so begabt bist, zwingt dich keiner PA zu nutzen. Nichts leichter als es zu deaktivieren.
Stimmt! Habe vergessen, dass Energyman die Referenz des Seins darstellt. Was Energyman nicht braucht, kann die Menschheit auch nicht haben wollen. Warum meinst du eine qualifizierte Aussage zu diesem Thema machen zu können, wenn du noch nie einen Daemon benutzt hast? Trollerei?
Im Übrigen: Versuche mal unter dem, was "funktioniert" einen Audio-Stream von einem Device auf ein anderes zu verschieben. Achso... Du brauchst es nicht, also hat es auch keiner zu brauchen.
Das ist ja schön, wenn ich mit Pulseaudio in der Theorie Kaffee kochen kann, in der Praxis nerft es aber schon, wenn der Sound in z.B. Quake 3 gar nicht und in OpenAL Spielen wie Glest3D nur völlig gestört ausgegeben wird.
Hab ich nie verwendet. Natives Alsa reichte und reicht aus. Ganz ohne PA gehts leider doch nicht weils blöd ist, wenn man gerne die im Desktop integrierte Lautstärkeregelung verwenden möchte, die zwingend PA benötigt. Oder die Hotkeys (Lautstärke) incl. OSD funktionieren dann auch nicht mehr.
Da hat jetzt dieser Mensch keine Schuld sondern die Gnome-Entwickler und Distributoren haben das so ins System veranktert. Er ist aber die Ursache.
Gerne darf jeder seinen Sounddaemon/-system verwenden, aber dann bitte OPTIONAL. Weil das wars dann mit Linux und der angeblichen Freiheit.
>> dass Arts, ESD, Jack und wie sie alle heissen >Hab ich nie verwendet. Natives Alsa reichte und reicht aus.
Natürlich. Deshalb haben Leute auch ihre Kernel extra auf geringe Latenz und Jack-Support gepatched. Dieses ganze Durcheinander ist mit ein Grund dafür, dass kreative Audiosoftware noch immer auf einem Niveau mit der entsprechenden Windowssoftware von 1994 ist.
>Gerne darf jeder seinen Sounddaemon/-system verwenden, aber dann >bitte OPTIONAL. Weil das wars dann mit Linux und der angeblichen >Freiheit.
Es ist z.B. nicht Linux-spezifisch. Sehr wichtig nebenher gesagt. Eine längere Liste kann ich dir zusammenstellen, aber ich glaube nicht das dein Beitrag ernst gemeint ist, daher spar ich es mir.
Wenn es dich aber ernsthaft interessiert, installier es doch einfach mal. Bei Ubuntu (damit habe ich es zuletzt getestet) war es ein klacks das ganze einzurichten, 4Front bietet fertige Pakete an.
also ich persönlich brauch nur dmix und ein par andere alsa plugins. weil ich dank dessen nettes upmixing erstellen kann mit lowpass usw. usf. Was ich mir wünschen würde wäre, dass sich die alsa-leute mal eine konfigurationsmöglichkeit anbieten würden, die nicht nur komplette vollfreaks sondern normale menschen verstehen.
Jack hat mit der Diskussion über Pulseaudio eigentlich auch nichts zu tun. Für den professionellen Audioanwender ist es aber bestimmt ein schönes tool.
Pulseaudio ist an sich ja ganz nett, da es Applikationsbezogene laustärkeregelungen und sonstige soundeinstellungen bieten kann. Aber es mach den fehler, dass es Aufgaben die alsa viel besser beherrscht zu duplizieren zum beispiel das besagt upmixing .... pulseaudio sollte wenn überhaupt alsa so einstellen diese sachen korrekt vorzunehmen. Aber in der realität macht Pulse das zuerst selbst und gibt es dann an alsa weiter. Zudem ist Pulse immernoch zu langsam und instabil.
Und die Tatsache, dass du OSS Support für eine Hürde hältst lässt auch recht tief blicken. OSS-Clients laufen wunderbar über das alsa-oss backend.
> Weil das wars dann mit Linux und der angeblichen Freiheit
Die Freiheit ist nicht "angeblich", wohl aber von dir missverstanden. Freiheit bedeutet nicht, dass jeder Entwickler in seinem Projekt alles optional und konfigurierbar machen muss.
von mir aus kann ja auch jeder machen was er will. aber wenn man dann irgendwelche libarys nichtmehr ausseinem system entfernen kann weil der programmierer es nicht hinbekommen hat, dann kann manschon mal ein bisschen genervt sein.
Also bei mir funktionieren alle hotkeys und grafische lautstärkeregelung problemlos ohne pulseaudio. auch auf den von mir betreuten ubuntu-maschinen ...... irgendwas machst du eindeutig falsch. (libpulse oder so darf man natürlich nicht löschen <-- das ist der eigentliche fehler in dem System)
Ohne Recherche zu Polemisieren ist auch witzlos: KDE kann Pulseaudio benutzen (und tut es bei mir, ebenfalls Opensuse, per Default auch), ist allerdings nicht darauf beschränkt.
Nichts für ungut, aber schonmal auf die Versionsnummer geguckt?
Es liegt nicht daran, dass PulseAudio so schlecht ist, es ist einfach nur zu neu. Alsa hat auch nicht von gestern auf heute reibungsloser funktioniert als OSS.
>Wenn man in seinem Blog so seine Kommentare liest, hat der echt >nen Knall: immer sind alle anderen (Hardware, Treiber, Distributor, >Programm) Schuld, nur er nicht.
Oft ist es so, dass bei neuer Software ans Licht tritt, wo sich Distributoren und andere Entwickler nicht an Konventionen gehalten haben. Deshalb muss neue Software halt getestet werden und Workarounds ermöglicht werden, ggf. auch bei anderer Software.
Letztendlich ist der Grund für dein Ärgernis nicht PulseAudio, sondern die Tatsache, dass das Distributoren (nicht erst seit gestern) alte Software durch neue unfertige Software ersetzen. Bestes Beispiel ist KDE4.0, von den Entwicklern als unfertig deklariert und trotzdem von den Distributoren breit eingesetzt.
Wie ich finde, regelt Ubuntu das ganz gut mit seinen LTS-Releases. (Übrigens war KUbuntu 8.04 aus gutem Grund kein LTS-Release...)
>Und jetzt möchte dieser Typ etwas programmieren, was PID 1 >besetzt? Gehts noch??? Diese Distribution(en) werde ich NEVER >EVER, NIE NIE einsetzen. Vorher wechsle ich noch zu FreeBSD.
Wozu ist PID 1 gut, wenn es nicht benutzt wird? Zum Anbeten?
Wie dem auch sei, ich freue mich, wenn PulseAudio eine Reife wie Alsa erreicht hat. Dann kann ich mit meinem Notebook chillig irgendwo sitzen und trotzdem kabellos guten Anlagensound genießen.
Wenn es denn mal endlich stabil wird dann könnte man ja tolle Sachen machen. Hauptsache immer Baustelle nicht wahr? Das ist ja weit wichtiger als endlich mal eine rundum funktionierende Distribution zu haben. Basteln is angesagt und wer nicht basteln will ist gleich ein Verweigerer... -.-
So wars nicht gemeint, ich habe selber keine Lust mehr auf große Bastelaktionen. Aber wie gesagt, Ubuntu LTS ist eine Lösung, die ich benutze. Zumindest bei LTS 8.04 ist es ein Kinderspiel PulseAudio zu umgehen. Denke mal, dass es mit LTS 10.04.1 or 10.04.2 so weit getestet ist, dass es auch da perfekt funktioniert.
Eigentlich laufen nur Server permanent. Usergeräte möchte man gerne aus Akku-, Stromspar- und Umweltgründen ganz ausschalten. Und gerade bei z.B. Tablet-Systemen für die Sofaritze, wie sie sich bald verbreiten werden möchte man nicht erst eine halbe Minute booten, nur um für 10 Sekunden das Fernsehprogramm, einen Wikipedia-Artikel oder ein Kochrezept nachzuschauen.
Steht eigentlich schon alles im Betreff. Schön und verständlich geschrieben, und auch systemd hört sich nach einem guten Konzept an. Bleibt nur zu hoffen, dass es auch in die richtige Richtung geht, und nicht nachher in eine falsche Richtung gelenkt wird.
Von Festplattenbremse am Sa, 1. Mai 2010 um 17:14 #
Ich frage mich eigentlich, was dieser Unsinn soll möglichst alle Prozesse Parallel zu starten, obwohl wir alle wissen, daß der Schreiblesekopf einer Festplatte gar nicht für das hin und herspringen auf der Platte besonders gut geeignet ist. Denn am meisten Zeit fressen heutzutage sicher die Lesezugriffe, insbesondere dann wenn der Lesekopf hin und herspringen muß, während die CPU auf die Daten warten muß.
Daher wäre es meiner Meinung nach am sinnvollsten, wenn man alle notwendigen Prozesse sequenziell von der Platte lesen würde. Geeignet erscheint mir hier eine Art Cache* oder binärer Block* der schon alle Prozesse in der richtigen Reihenfolge enthält und welcher nur noch sequenziell in den Speicher geladen werden muß und von dort kann man dann ja einen regulären Systemstart mit seinen vielen Abfragen, Wartezeiten, Verzweigungen usw. fortführen, aber die wichtigsten Priozesse sollten erstmal in einem Rutsch in den Speicher geladen werden.
DAS würde den Systemstart wirklich beschleunigen, denn nichts ist so langsam wie die Festplatte und es hat ja nicht jeder eine SSD im Rechner.
* Der Cache oder Block würde beim ersten Start auf normale Weise wie bei einem normalen Systemstart generiert werden müssen. Aber dannach wären alle Neustarts dann effizient und schnell und falls Fehler auftreten, dann generiert man den Cache oder Block neu.
Ja ein Dateisystem das lernt in welcher Reihenfolge welche Dateien immer gelesen werden und auch schreib/lese Häufigkeiten misst und danach die Daten auf der Platte umordnet wäre halt super. Ist gar nicht so neu, die Idee. Und angeblich arbeitete Microsoft an so was (oder ist das schon in Windows 7? kA).
Fedora readahead macht so was Ähnliches. Es liest die Dateien in der Reihenfolge, wie sie physisch auf der Disk liegen.
Vermutlich ist der Effekt kleiner, als du denkst. Ob man es braucht, hängt davon ab, ob die Platte schon am Anschlag ist. Eine allgemeine Aussage kann ich dazu nicht machen. Ich weiß nur, dass es Debian und Ubuntu im Archiv haben, aber nicht vorinstallieren.
Wann baut endlich mal jemand eine Festplatte, bei der jede Spur ihren eigenen Schreib/Lesekopf hat? Die Seek-Zeit wäre dann nur noch von der Rotationsgeschwindigkeit abhängig und die Übertragungsrate astronomisch.
Festplatten für den Systemstart haben wir jetzt. Ich bin fast sicher, dass mein nächster Rechner (ist wohl noch 1 Jahr weg) von einer SSD bootet, wo die Sequenz praktisch keine Reihenfolge mehr spielt.
Die relevanten Entwickler im Linux-Umfeld scheinen eh schon lange SSDs zu haben. Und es ist daher kein Zufall, wenn man liest, dass btrfs mit SSDs besser zurecht kommt.
Die Festplatten sind Archiv, etc. und hat mit dem Boot nicht mehr viel zu tun.
Dazu kommt, dass ich nur sehr selten boote und im Grunde nicht booten will.
Auf meinem Laptop funktionier das traumhaft. Ich habe ein Wortmann Laptop, dessen BIOS nur 1 Sekunde braucht und damit macht es einen über Monate Suspend to Disk nach dem anderen.
Und dennoch ist damit in ein paar Sekunden wieder online, mit Fenstern, die teilweise seit Monaten laufen.
Dazu liest er völlig sequentiell ein Image mit maximaler Geschwindigkeit. Seit ich (wegen KDE4) auf XFCE umstieg, ist es noch ein wenig besser, da das Image noch kleiner wurde und subjektiv nach dem Suspend wirklich alles da ist. Das sind nur ein paar Hundert MB und das schafft die Disk in ein paar Sekunden und eben völlig sequentiell.
Dazu muss man natürlich auch sagen, dass ich deshalb Speicher spare, indem ich unnötige Services wie avahi-daemon entferne.
Nett ist auch der "nodm" (apt-get install nodm; apt-get remove gdm kdm) der quasi Nichts kann ausser mich automatisch einloggen, Passwort fragt bei mir das BIOS ab.
Ich würde mir wünschen, dass mein Desktop auch den Suspend und Resume schafft. Damit hatte ich zwar bisher kein Glück, sollte es aber wohl mal wieder versuchen. Habe ich länger nicht versucht, und vielleicht spiele ich ja doch mal das BIOS Update auf. In jedem Fall kann es der nächste Rechner, den ich kaufe, wie gesagt noch ne Weile weg.
Ich finde das Problem ist nicht, dass booten lange dauert (was ja auch nicht stimmt). Das Problem ist doch, dass man überhaupt booten muss.
Das beliebeste Feature an KDE war bei mir immer das automatische "Session-Restore", wo die Dokumente sich wieder so öffnen, wie sie vorher waren. Also die Konsole-Tabs, etc.
Nur warum sollten die Terminals überhaupt neu starten? Warum sollte auch nur ein Detail meines Desktops sich ändern? Warum setzt man nicht einfach immer fort?
Auf Telefonen ist es ja auch schon so. Und mit Suspend to Disk zieht das Umwelt-Argument für die PCs auch nicht mehr.
Daher finde ich, dass der hier vorgeschlagene Dienst sinnvoll ist, weil er den CPU/Speicher Verbrauch zur Laufzeit reduziert und die Features harmoniert. Denn dass "at" anders als "cron" anders als "init.d" anders als "inittab" anders als "Autostart" anders als ... funktioniert, ist ja nur lästig.
Und die Hoffnung, dass dann der sshd oder auch eine Datenbank nur dann läuft, wenn ich ihn wirklich anspreche, wäre wirklich nett, einfach weil es den Speicherdruck noch weiter senken würde. Vielleicht integrieren solche Services sich dann mit einem solchen Dienst und sowas wird gemacht. Dass es heute schon ginge ist ja klar.
Aber schneller booten? Interessant, aber nicht zwingend ein so gravierendes Thema wie schnelles Fortsetzen sein sollte.
Von Festplattenbremse am So, 2. Mai 2010 um 23:37 #
Also bei Slackware ist inetd dabei und wird auch genutzt.
Wenn du es für sshd auch nutzen willst, dann mußt du das eben entsprechend einrichten. Schwer ist es ja eigentlich nicht, ist ja nur ne Zeile in der Configurationsdatei.
Nein, das ist schlicht falsch. Die meiste Zeit fressen beim Boot nicht die Festplattenzugriffe. Die meiste Zeit wird in die serielle Initialisierung von Systemen und Geräten verbraucht. Die zu parallelisieren bringt am meisten. Schaue dir einfach nur den Bootprozess an und messe ihn mit geeigneten Tools. Das ist leicht messbar und ziemlich unbestritten.
Jaja nur nichts neues Was der Bauer nicht kennt frisst er nicht
Schon mal dran gedacht wieder Windows zu installieren? Kein paketmanagment, kein konstistentes System aber Hauptsache abwärtskompatibel bis zum Erbrechen damit man ja keinen DAU erschreckt
> Ach komm... als gäbe es auch nur eine > Linuxdistribution welche wirklich konsistent > wäre.
Zeig mir EINE deren Paketmanagment inkonsistent wäre!
Und ja, bei einem OS + Software ist das so ziemlich das wichtigste. Ich fahre meine Fedora-Installation seit einigen Jahren unverändert auf dem dritten Rechner und zwar mit einem Haufen Developer-Tools und Serverdiensten die nicht mit 3 Klicks eingerichtet sind.
Klar muss man das System pflegen Aber zeig mir doch eine Windows-Installation die ohne nennenswerte Probleme von einem Rechner auf einen völlig anderen umzieht und dabie auch noch ein Komplett-Upgrade macht
Ts... Ich finde die Kommentare auf Prolinux teils lustig teils auch irgendwo beschämend.
Wann immer ich die (trolligen?!) der und der ist Schlecht, oder dass und das ist total sch**** oder oh mein Gott der nicht lese, frage ich mich was für Erwartungen die Leute ham...
Falls jemand weiterlesen möchte, die nächsten Zeilen sind mein subjektiver Eindruck...
a) generell (und das betrifft auch Pulseaudio): Es ist nicht irgendein GUI Programm bei dem man Risiken und mögliche Fehlerquellen abschätzen und einfach ausloten kann (verschiedene Distributionen und distributionsspezifische Sachen, verschiedene Kernel, Treiberversionen, Desktopversionen, Kernelbuilds usw... ) Bei einem GUI Programm hat man, bis zu einer gewissen Komplexität, einen Überblick...
b) Pulseaudio hat vieles vereinfacht... Und dieses plattreden eines Projektes... Sorry, ich muss da immer an Erfahrungen im Kundenbereich denken, Lieblingsaussage: Ja ich hab ja gegooglet und einfach alles mögliche ausprobiert was da stand...Google ist toll Google ist mächtig, aber Google kann nicht prüfen welche Sachen sinnvoll sind oder nicht [Beispiel: Erstellung von Konfigurationsdateien, ala .asoundrc oder /etc/asound.conf ohne sich bewusst zu sein was es tut... Oder dass die nötigen alsa-plugins installiert sind...] Und dass ist es meistens... Oder aber das typische Probleme mit YouTube verses PA. Pulseaudio ist natürlich schlecht, weil Flash ja nur proprietär ist und ein Audiogerät blockiert. Aber PA ist böse!
c) Ohne eine große Quelle von Bugreports um auf die Komplexität von a eingehen zu können, ist es de fact unmöglich etwas zu verbessern. Und ich finde wenn man sich die Releases von Pulseaudio anschaut hat er meist nicht lange gefackelt falls gravierende Probleme existierten. ( hier sei der Hinweis gegeben: Bugfix ist ungleich Feature und Feature ist ungleich Bugfix. Verstehen auch einige Menschen nicht so ganz... )
d) Wenn ich bedenke dass viele Leute einfach nur das heulen anfangen und dann sagen der und der ist schuld, frag ich mich warum Sie es dann überhaupt tuen. Warum zieht ihr die jahrelange Arbeit, Debuggen, Fixen, releasen, Mailstress, private Zeit usw die ein Mensch investiert habt, in Frage? Wenn jemand tatsächlich seine Zeit so fehlinvestiert hätte, dann versteh ich nicht warum PulseAudio von vielen Leuten so gelobt wurde... (ich hatte nie Probleme, bis auf Flash und dass ist kein Problem im Sinne von PA) Und warum es dann auch noch in Distributionen eingesetzt wird, keine Ahnung. Scheinbar konsumieren alle Entwickler LSD und drücken wie wild doofe Knöpfe und es funktioniert [man beachte die IRONIE und den SARKASMUS... ]
Sorry dass hätte ich bissel klarer schreiben sollen.
Dass Problem existiert nicht mehr bzw sollte nicht mehr existieren... Es war nur früher ein typisches Problem - und darauf bezog sich auch der Kommentar der fehlenden alsa-plugins...
Hatte mich etwas "überschlagen" in der Hinsicht
Aber genau dieses "Problem" brachte Leute dazu Pulseaudio zu hassen...
Pulseaudio ist natürlich schlecht, weil Flash ja nur proprietär ist und ein Audiogerät blockiert. Aber PA ist böse!
Es kann doch nicht ernsthaft davon ausgegangen worden sein, man müsse alle Programme anpassen, damit sie mit PulseAudio funktionieren? Wie kann überhaupt ein userspace Programm exklusiven Hardwarezugriff erlangen?
Das hat nichts mit exklusivem Hardwarezugriff zu tun. Eher damit, dass Steinzeit-Soundtreiber (und alles was in die Richtung geht) gleichzeitig nur ein einzelnes Programm bedienen können. Um mehrere Sounds gleichzeitig ausgeben zu können, bedarf es etwas modernerem Gerät...
> OSS kann das noch nicht so lange. > Tragischerweise gibt es noch immer > Anwendungen, die OSS benutzen bzw. > nur damit richtig funktionieren.
Das ist dann aber Pech Würden sie ALSA benutzen hättest du das Problem nicht und mit pulseaudio würden sie auch laufen
Installierte Pakete Name : alsa-plugins-pulseaudio Architektur : x86_64 Version : 1.0.22 Ausgabe : 1.fc12 Grösse : 93 k Repo : installed Aus repo : updates Zusammenfassung : Alsa to PulseAudio backend URL : http://www.alsa-project.org/ License : LGPLv2+ Beschreibung:This plugin allows any program that uses the ALSA API to access a PulseAudio : sound daemon. In other words, native ALSA applications can play and record : sound across a network. There are two plugins in the suite, one for PCM and : one for mixer control.
Sorry, aber ich glaube du verkennst die Realität. In der Praxis sieht es so aus. das pulseaudio theoretisch fast alles kann. In der Praxis aber durch ein paar Grundsatzentscheidungen sich selbst ins Abseits befördert. Es resampled alles und Linux kann kein RT standardmässig. Wie gesagt die Designidee ist gut, die Ausführung mangelhaft. Warum will man alles resamplen/zusammenmixen in Software wenn man ebenso die Fähigkeiten der zugrundeliegenden Hardware ausloten könnte. Wenn es für ein bischen Gebimmel hier und etwas Geplärre da geht, aber versuche AC3, DTS oder ähnliches. Auch Musikhören macht mit Verzerrungen bei Last keinen Spass, ein simpler Voicechat braucht 30% CPU Leistung auf mittleren Systemen.
Die Leistung verkenne ich sicher nicht. In manchen Teilen hat er sogar Recht. Ich befürchte nur dass das wieder das rigide Umsetzen einer Theorie wird - die in der Praxis so nicht funktioniert.
Ja ich benutze fast 100% upstart und die Probleme die er beschreibt sind in der Tat so vorhanden. Bei der Hälfte aller Jobs die ich so geschrieben habe musste ich irgendwelche while schleifen einfügen die sicherstellen das der Dienst wirklich da ist. Ausserdem sind die Abhängigkeiten teilweise die Hölle wenn man etwas mehr versucht als nur einen Webserver zu starten.
"Warum will man alles resamplen/zusammenmixen in Software wenn man ebenso die Fähigkeiten der zugrundeliegenden Hardware ausloten könnte."
Macht Pulseaudio das auch (anscheinend "in Software"?), wenn Soundkarten wie SB Live oder SB Audigy vorhanden sind, die Hardware-Mixing beherrschen? Nein, oder?
Zumindest bis ich den vorletzten Satz las - hier wird scheinbar wieder eine eilerlegende Wollmilchsau gebaut.
Lies den mit Argumenten gespickten Originalartikel, die Sessionmanager und das Initsystem mit deiner Daemon-Überwachung machen weitestgehend dasselbe. Warum sollte man die Funktionen nicht in einer gemeinsamen Codebasis zusammenführen?
Eierlegende Wollmilchsau ist die negative Annäherung an den Ansatz, Entrümpelung redundanter Dienste und Verschlankung der Systemprozesse klingt doch viel schöner. Wir werden sehen.
Es ist trotzdem vollkommen unrealistisch das KDE und GNOME diese System verwenden werden, weil beide DEs auch auf vielen anderen Plattformen und nicht nur Linux laufen.
Weder Gnome, noch KDE werden diesen Dienst explizit benutzen müssen. Sobald eine Destopumgebung läuft, ist die Funktionalität von systemd mindestens einmal abstrahiert.
Oder anders gesagt: Gnome und KDE bekommen gar nicht mit, dass irgendwo weiter unten systemd läuft.
The problem set of a session manager and an init system are very similar: quick start-up is essential and babysitting processes the focus. Using the same code for both uses hence suggests itself. Apple recognized that and does just that with launchd. And so should we: socket and bus based activation and parallelization is something session services and system services can benefit from equally.
Klingt spannend und auch der Originalartikel erweckt den Eindruck, dass hier jemand die Sache basierend auf den Erfahrungen und Designsünden vergangener Jahrzehnte nochmal grundlegend aufgebaut hat. Dabei hat er auch über den Tellerrand geschaut und sich von Lösungen inspirieren lassen, die auf anderen Systemen überzeugen konnten.
Ich hoffe, es springen jetzt weitere Entwickler, vielleicht ein paar seiner Red Hat Kollegen, auf und der Dienst schafft es für erste Feldtests und Weiterentwicklungen schnell nach Fedora.
Ich ärgere mich darüber, wie schlecht eigentlich der Bootprozess bisher mit initd abläuft, obwohl ein bisschen Graphentheorie ausreicht, um was besseres zu erzeugen, um es zu beschleunigen.
Ich bin Informatiker und entwickle Software und leider verkennen viele die Möglichkeiten der Systematisierung und Parallelisierung. "Der Verwaltungsaufwand ist zu groß." oder "Das versteht doch keiner." höre ich immer wieder. Wie ein Compiler funktioniert, wissen viele auch nicht und trotzdem wird's verwendet, inklusive der vielen vorgefertigten Frameworks.
Und die ganzen Optimierungen die ein Kompiler durchführt sind i.d.R. komplexer als das auflösen von Dienst-Abhängigkeiten, würde ich schätzen. (Kann ja sein das ich dabei was übersehe.)
"Kann ja sein das ich dabei was übersehe."
Ja du übersiehst was, das Auflösen von Abhängigkeiten reicht ja hier nicht.
Das schwierige ist, dass es hier nicht nur um statische Zustände geht 0,1 an aus. Sondern es geht z.B. um die Frage was tun, wenn ein abhängiger Dienst nicht startet oder verzögert etc. das sind die Herausforderungen.
Als Informatiker kannst du ja sicher programmieren und das mal richtig implementieren, wenn das schon so einfach ist. Ich bin gespannt.
In solchen Projekten entscheidet nicht ein einziger, wie etwas abläuft. Aber seien wir ehrlich: Der init-Vorgang sieht aus wie ein großer Hack und damit Dienste in der richtigen Reihenfolge gestartet werden, müssen sie durchnummeriert werden. Ich musste auch feststellen, dass run-parts keine Dateien akzeptiert, die auf .sh enden. Man schleppt historische Altlasten mit sich, was einerseits sehr interessant ist, Programme laufen zu haben, die sich seit zehn Jahren nicht mehr geändert haben, aber andererseits wird es den Nutzer schwer gemacht, weil viele Werkzeuge sich seltsam verhalte, wie z. B. run-parts.
Schwierig am init-d Prozess sind wohl die Seiteneffekte. Ich weiß jetzt nicht, wie weit der im Regelfall alles konfiguriert und inwieweit andere Anwendungen init.d konsultieren. Sehr beleibt: Schauen, ob eine Datei im Init.d-Order existiert und davon das Verhalten abhängig machen. Das macht die Sache kompilziert.
Beruflich hatte ich auch mit so einem Init-Ding zu tun, der für das firmeneigenen Framework entwickelt wurde und für die Kernanwendung mehrere Prozesse startet. Die haben auch wieder den Unsinn mit den Zahlen gemacht: Hauptsache, es ist richtig durchnummeriert. Dabei müsste man nur Abhängigkeiten modellieren, topologisch sortieren und das Ding ist fertig, robust und der Verwaltungsaufwand ist minimal. Es wird verkannt, wieviel Zeit so Konfigurationsdinge mit sich bringen. Selbst Leute unterschätzen es, die es eigentlich besser wissen müssten, weil sie über Programmiererfahrung verfügen.
Wow, mal wieder ein richtig schöner Artikel. Ausführlich und verständlich. So mag ich das. Danke für die Mühe Hans-Joachim!
Ich frage mich, wie groß der Bedarf daran ist dynamisch Deamon-Abhängigkeiten aufzulösen. Ich muss dazu sagen, dass ich kein erfahrener Linux-Admin bin und vielleicht fehlt mir dazu einfach die nötige Praxis. Aber wie viele Deamonen gibt es denn so? 10, 20? Ich bin der Meinung derartige Abhängigkeiten einmal bei der Produktion einer Distribution zu berücksichtigen ist doch wirklich kein Problem. Dann kann man das doch auch parallell starten lassen, was sich parallel starten lässt. Bei Arch funktioniert das auch.
Ansonsten klingt systemd ja ganz gut. Aber ein Sessionmanager finde ich da deplaziert. Wenn KDM und GDM die gleiche Funktion erfüllen, wäre es meiner Meinung eher an Freedesktop.org da mal etwas zu tun.
Abgesehen davon, hätte man sich vielleicht mal mit Upstart-Entwickler kurzschließen können. Jetzt zwei Dienste zu entwickeln, die zu einem großen Teil die gleiche Funktionen haben soll, finde ich auch mehr als unglücklich.
Ja, also bei mir auf dem Server laufen genau 15 Services.
Auf den Clients sind es aber deutlich weniger, ca. 5.
Upstart kannst du uebrigens nicht mit systemd vergleichen, da die grundlegenden Konzepte ganz andere sind. Das faengt ja schon bei der Programmiersprache an.
Es geht ja nicht um Server, sondern Desktopsysteme. Wen stört die Startgeschwindigkeit bei Servern? Niemand. Die Startet man ja nicht täglich sondern vielleicht alle 100 Tage mal...
Jo, und dann dauerts sowieso ewig wegen fsck...
Nur so gaaanz zufaellig ist der PulseAudio Autor auch derjenige, der es in Fedora betreut:
http://admin.fedoraproject.org/pkgdb/acls/name/pulseaudio
Fehler passieren ueberall.
Dieser Spa*ti hat ein funktionierendes AudioSystem zerstört, daß vorher einfach funktionierte. Scheinbar ist es langweilig und out, wenn mal etwas funktioniert.
Seitdem PulseAudio in den üblichen Distributionen Einzug hielt und ständig Probleme bereitete, durfte ich bei Fedora, Ubuntu, Suse & Co ständig am PulseAudio rumfrickeln, bis ich dann entnervt komplett Slackware verwendete.
Wenn man in seinem Blog so seine Kommentare liest, hat der echt nen Knall: immer sind alle anderen (Hardware, Treiber, Distributor, Programm) Schuld, nur er nicht.
Mit den Stunden, in denen ich mich mit PulseAudio geärgert habe, ist er ein rotes Tuch geworden.
Und jetzt möchte dieser Typ etwas programmieren, was PID 1 besetzt? Gehts noch??? Diese Distribution(en) werde ich NEVER EVER, NIE NIE einsetzen. Vorher wechsle ich noch zu FreeBSD.
Du siehst das ja sehr differenziert...
Geh woanders trollen.
> Scheinbar ist es langweilig und out, wenn mal etwas funktioniert.
"Wir bauen auf, wir reißen nieder, Arbeit gibt es immer wieder."
> immer sind alle anderen (Hardware, Treiber, Distributor, Programm) Schuld, nur er nicht.
Stimmt doch. Er ist halt ein Genie! Unable to fail, Dreppersyndrom.
> Dreppersyndrom.
Red Hat hat leider noch mehr Leute von der Sorte auf der Gehaltsliste, und dummerweise an zentralen Stellen wie X.Org oder Audio. David Airlie hat sich ja auch gerade erst wieder beliebt gemacht.
Das führt dann am Ende zu Distributionen wie Fedora, der Messlatte für Stabilität.
> > Dreppersyndrom.
> Red Hat hat leider noch mehr Leute von
> der Sorte auf der Gehaltsliste
Nein, RedHat hat GOTT SEI DANK solche Leute auf der Gehaltsliste.
Kann es sein dass du einfach nicht die Qualifikation hast zu begreifen was genau diese Leute in den letzten Jahren geleistet haben?
> und dummerweise an zentralen Stellen
> wie X.Org oder Audio.
Und dem Kernel und Apache und so weiter
Schau dir doch mal alleine beim httpd an welche Domain hinter den meisten Security-Fixes der letzten Jahre steht
Und Nein das heisst bei Gott nicht dass der gleiche die Lücke rein gemacht hat
> David Airlie hat sich ja auch gerade erst
> wieder beliebt gemacht.
Ein guter Techniker hat es nicht nötig sich beliebt zu machen. Langfristige Entscheidungen treffen die auch mal weh tun beisst sich mit beliebt machen, nur mit Leuten die beliebt sein wollen bricht das ganze aber mittelfristig zusammen weil es irgendwann zu spät ist grundlegende Änderungen zu machen und ab dann bringt es plötzlich keinem was wenn 10 Jahre alle nett und beliebt waren.
Dann heisst es plötzlich "Na hätten sie doch" und "Woher hätte ich wissen sollen" - Genau deswegen sollten manche Dauerkritiker sich mal Fragen ob sie in ihrem Leben auch nur ansatzweise solche Leistungen gebracht haben und überhaupt in der Lage sind etwas so weit zu verstehen um es kritisieren zu können.
> Das führt dann am Ende zu Distributionen
> wie Fedora, der Messlatte für Stabilität.
Wo genau ist dein Problem mit Fedora?
Wenn du sofort nach Release ein Dist-Upgrade machst kann da kein Mensch was dafür ausser Du selbst.
Kann man machen wenn man mit dem System wirklich umgehen kann und auch etwas Spass am Basteln hat - Mache ich seit Jahren auf meiner Arbeitsmaschine.
Auf den Servern läuft immer Dist-1 und kurz vor Ablauf des Supports von F11 kommt F12 drauf. Wenn man zu dumm ist das zu handhaben muss man halt ein RHEL/CentOS nehmen, darf dann aber auch nicht rumflennen wenn ein Paket zu alt ist
> Kann es sein dass du einfach nicht die Qualifikation hast zu begreifen was genau diese Leute in den letzten Jahren geleistet haben?
> Kann man machen wenn man mit dem System wirklich umgehen kann
> Wenn man zu dumm ist
Argumentum ad hominem. Ich denke nicht dass es Sinn macht auf der Ebene weiter zu diskutieren.
> Argumentum ad hominem.
> Ich denke nicht dass es Sinn macht auf
> der Ebene weiter zu diskutieren.
Schön für dich dass du in der Lage bist eine paar Sätze die dir nicht passen aus dem Kontext zu reissen und dich daann wie ein kleines Kind in die Ecke zu stellen und "so nicht" zu schreien
95% der Argumente hast du einfach locker ignoriert weil du dazu entweder mangels Hintergrundissen nichts sagen kannst (OK das müsste man dir dann hoch anrechnen) oder nicht willst weil du nicht dazu stehen willst es dir mit Kritik halt einfach zu machen.
> Stimmt doch. Er ist halt ein Genie! Unable to fail, Dreppersyndrom.
Der Vergleich hinkt. Drepper ist halt wirklich begabt. Mangelnde Diskussionsbereitschaft kann man ihm (Drepper) eigentlich auch nich vorwerfen, er engagiert sich ja auch jenseits von Redhat z.B. in Opengroup-Gremien.
Stimmt leider, PulseAudio fliegt bei mir auch immer als Erstes von der Platte.
Ja, PulseAudio hat auch bei mir das Soundsystem für lange Zeit zurück in die 90er verfrachtet. Jetzt funktionierts wieder so allmählich. Ab und zu hab ich noch Hacker, e.g. wenn ich Musik pausiere und dann stoppe o.ä., aber im Großen und ganzen gehts jetzt wieder. Hat ja lange gedauert. Aber warum an etwas das eh hervorragend funktioniert hat so herumgepfuscht werden musste versteh ich auch nicht. Ein/zwei Distri Releases lang war Sound unter Linux einfach nur Horror. Mit fast Sekundenlange Latnecy. Spiel so mal ein Spiel! Das macht echt keinen Spaß. Das man eine Sekunde warten muss wenn man play/pause in einen Audioplayer drückt ist da ja noch fast verschmerzbar. Und sagt nicht es liegt an Hardware/Treiber/Programmen, denn alles das hat früher mit reinem ALSA bzw. Windows auf der selben Hardware (und mit den selben Programmen) vollkommen einwandfrei funktioniert.
Dieser Spa*ti hat ein funktionierendes AudioSystem zerstört, daß vorher einfach funktionierte.
Haha! Selten so einen gute Witz gehört. Das System funktionierte so gut, dass Arts, ESD, Jack und wie sie alle heissen eigentlich nur so aus Scherz gemacht wurden. Schliesslich funktionierte das System so gut...
Endlich hat sich jemand diesem Haufen Müll angenommen und mit PA etwas erstellt, was auch mit Windows und Mac konkurrieren konnte. Zuvor war Linux auf diesem Sektor in der Steinzeit. Gott sei dank hat sich es nun geändert.
Im Übrigen... Da du ja so begabt bist, zwingt dich keiner PA zu nutzen. Nichts leichter als es zu deaktivieren.
es funktioniert so gut, daß ich noch nie einen Sound-daemon benutzt habe.
hmm.. und irgendwie vermisse ich nichts.
Stimmt! Habe vergessen, dass Energyman die Referenz des Seins darstellt. Was Energyman nicht braucht, kann die Menschheit auch nicht haben wollen. Warum meinst du eine qualifizierte Aussage zu diesem Thema machen zu können, wenn du noch nie einen Daemon benutzt hast? Trollerei?
Im Übrigen: Versuche mal unter dem, was "funktioniert" einen Audio-Stream von einem Device auf ein anderes zu verschieben. Achso... Du brauchst es nicht, also hat es auch keiner zu brauchen.
Das ist ja schön, wenn ich mit Pulseaudio in der Theorie Kaffee kochen kann, in der Praxis nerft es aber schon, wenn der Sound in z.B. Quake 3 gar nicht und in OpenAL Spielen wie Glest3D nur völlig gestört ausgegeben wird.
Du bist ein Idiot.
> dass Arts, ESD, Jack und wie sie alle heissen
Hab ich nie verwendet. Natives Alsa reichte und reicht aus. Ganz ohne PA gehts leider doch nicht weils blöd ist, wenn man gerne die im Desktop integrierte Lautstärkeregelung verwenden möchte, die zwingend PA benötigt. Oder die Hotkeys (Lautstärke) incl. OSD funktionieren dann auch nicht mehr.
Da hat jetzt dieser Mensch keine Schuld sondern die Gnome-Entwickler und Distributoren haben das so ins System veranktert. Er ist aber die Ursache.
Gerne darf jeder seinen Sounddaemon/-system verwenden, aber dann bitte OPTIONAL. Weil das wars dann mit Linux und der angeblichen Freiheit.
>> dass Arts, ESD, Jack und wie sie alle heissen
>Hab ich nie verwendet. Natives Alsa reichte und reicht aus.
Natürlich. Deshalb haben Leute auch ihre Kernel extra auf geringe Latenz und Jack-Support gepatched. Dieses ganze Durcheinander ist mit ein Grund dafür, dass kreative Audiosoftware noch immer auf einem Niveau mit der entsprechenden Windowssoftware von 1994 ist.
>Gerne darf jeder seinen Sounddaemon/-system verwenden, aber dann
>bitte OPTIONAL. Weil das wars dann mit Linux und der angeblichen
>Freiheit.
Dann aber bitte auch mit Steinzeit-OSS-Support.
"Dann aber bitte auch mit Steinzeit-OSS-Support."
OSS-4 ist eine sehr mächtige Lösung.
Was kann OSS-4, was Alsa nicht kann?
"Was kann OSS-4, was Alsa nicht kann?"
Es ist z.B. nicht Linux-spezifisch. Sehr wichtig nebenher gesagt. Eine längere Liste kann ich dir zusammenstellen, aber ich glaube nicht das dein Beitrag ernst gemeint ist, daher spar ich es mir.
Wenn es dich aber ernsthaft interessiert, installier es doch einfach mal. Bei Ubuntu (damit habe ich es zuletzt getestet) war es ein klacks das ganze einzurichten, 4Front bietet fertige Pakete an.
also ich persönlich brauch nur dmix und ein par andere alsa plugins. weil ich dank dessen nettes upmixing erstellen kann mit lowpass usw. usf.
Was ich mir wünschen würde wäre, dass sich die alsa-leute mal eine konfigurationsmöglichkeit anbieten würden, die nicht nur komplette vollfreaks sondern normale menschen verstehen.
Jack hat mit der Diskussion über Pulseaudio eigentlich auch nichts zu tun. Für den professionellen Audioanwender ist es aber bestimmt ein schönes tool.
Pulseaudio ist an sich ja ganz nett, da es Applikationsbezogene laustärkeregelungen und sonstige soundeinstellungen bieten kann. Aber es mach den fehler, dass es Aufgaben die alsa viel besser beherrscht zu duplizieren zum beispiel das besagt upmixing .... pulseaudio sollte wenn überhaupt alsa so einstellen diese sachen korrekt vorzunehmen. Aber in der realität macht Pulse das zuerst selbst und gibt es dann an alsa weiter.
Zudem ist Pulse immernoch zu langsam und instabil.
Und die Tatsache, dass du OSS Support für eine Hürde hältst lässt auch recht tief blicken. OSS-Clients laufen wunderbar über das alsa-oss backend.
> Weil das wars dann mit Linux und der angeblichen Freiheit
Die Freiheit ist nicht "angeblich", wohl aber von dir missverstanden. Freiheit bedeutet nicht, dass jeder Entwickler in seinem Projekt alles optional und konfigurierbar machen muss.
von mir aus kann ja auch jeder machen was er will. aber wenn man dann irgendwelche libarys nichtmehr ausseinem system entfernen kann weil der programmierer es nicht hinbekommen hat, dann kann manschon mal ein bisschen genervt sein.
Also bei mir funktionieren alle hotkeys und grafische lautstärkeregelung problemlos ohne pulseaudio. auch auf den von mir betreuten ubuntu-maschinen ...... irgendwas machst du eindeutig falsch. (libpulse oder so darf man natürlich nicht löschen <-- das ist der eigentliche fehler in dem System)
openSUSE mit KDE kommt übrigens gänzlich ohne pulseaudio, da klappt's dann auch mit dem Sound.
KDEs Beschränkungen als Tugend darzustellen ist irgendwie witzlos, lieber Sebas.
Ohne Recherche zu Polemisieren ist auch witzlos: KDE kann Pulseaudio benutzen (und tut es bei mir, ebenfalls Opensuse, per Default auch), ist allerdings nicht darauf beschränkt.
Wo kämen wir auch hin, würden wir uns unter Linux auf ein Audiosubsystem einigen -_-
Zu Microsoft.
danke.
Nichts für ungut, aber schonmal auf die Versionsnummer geguckt?
Es liegt nicht daran, dass PulseAudio so schlecht ist, es ist einfach nur zu neu. Alsa hat auch nicht von gestern auf heute reibungsloser funktioniert als OSS.
>Wenn man in seinem Blog so seine Kommentare liest, hat der echt
>nen Knall: immer sind alle anderen (Hardware, Treiber, Distributor,
>Programm) Schuld, nur er nicht.
Oft ist es so, dass bei neuer Software ans Licht tritt, wo sich Distributoren und andere Entwickler nicht an Konventionen gehalten haben.
Deshalb muss neue Software halt getestet werden und Workarounds ermöglicht werden, ggf. auch bei anderer Software.
Letztendlich ist der Grund für dein Ärgernis nicht PulseAudio, sondern die Tatsache, dass das Distributoren (nicht erst seit gestern) alte Software durch neue unfertige Software ersetzen. Bestes Beispiel ist KDE4.0, von den Entwicklern als unfertig deklariert und trotzdem von den Distributoren breit eingesetzt.
Wie ich finde, regelt Ubuntu das ganz gut mit seinen LTS-Releases. (Übrigens war KUbuntu 8.04 aus gutem Grund kein LTS-Release...)
>Und jetzt möchte dieser Typ etwas programmieren, was PID 1
>besetzt? Gehts noch??? Diese Distribution(en) werde ich NEVER
>EVER, NIE NIE einsetzen. Vorher wechsle ich noch zu FreeBSD.
Wozu ist PID 1 gut, wenn es nicht benutzt wird? Zum Anbeten?
Wie dem auch sei, ich freue mich, wenn PulseAudio eine Reife wie Alsa erreicht hat. Dann kann ich mit meinem Notebook chillig irgendwo sitzen und trotzdem kabellos guten Anlagensound genießen.
Jo... wenn...
das hört man immer.
Wenn es denn mal endlich stabil wird dann könnte man ja tolle Sachen machen. Hauptsache immer Baustelle nicht wahr? Das ist ja weit wichtiger als endlich mal eine rundum funktionierende Distribution zu haben. Basteln is angesagt und wer nicht basteln will ist gleich ein Verweigerer... -.-
So wars nicht gemeint, ich habe selber keine Lust mehr auf große Bastelaktionen. Aber wie gesagt, Ubuntu LTS ist eine Lösung, die ich benutze. Zumindest bei LTS 8.04 ist es ein Kinderspiel PulseAudio zu umgehen. Denke mal, dass es mit LTS 10.04.1 or 10.04.2 so weit getestet ist, dass es auch da perfekt funktioniert.
Das kann ich auch jetzt schon.
dank esound und x-forwarding.
...soll das gut sein.
Systeme die permanet laufen brauch man doch nicht optimieren damit sie evtl. mal schneller starten; oder?
Eigentlich laufen nur Server permanent. Usergeräte möchte man gerne aus Akku-, Stromspar- und Umweltgründen ganz ausschalten. Und gerade bei z.B. Tablet-Systemen für die Sofaritze, wie sie sich bald verbreiten werden möchte man nicht erst eine halbe Minute booten, nur um für 10 Sekunden das Fernsehprogramm, einen Wikipedia-Artikel oder ein Kochrezept nachzuschauen.
Steht eigentlich schon alles im Betreff.
Schön und verständlich geschrieben, und auch systemd hört sich nach einem guten Konzept an. Bleibt nur zu hoffen, dass es auch in die richtige Richtung geht, und nicht nachher in eine falsche Richtung gelenkt wird.
Ich frage mich eigentlich, was dieser Unsinn soll möglichst alle Prozesse Parallel zu starten, obwohl wir alle wissen, daß der Schreiblesekopf einer Festplatte gar nicht für das hin und herspringen auf der Platte besonders gut geeignet ist.
Denn am meisten Zeit fressen heutzutage sicher die Lesezugriffe, insbesondere dann wenn der Lesekopf hin und herspringen muß, während die CPU auf die Daten warten muß.
Daher wäre es meiner Meinung nach am sinnvollsten, wenn man alle notwendigen Prozesse sequenziell von der Platte lesen würde.
Geeignet erscheint mir hier eine Art Cache* oder binärer Block* der schon alle Prozesse in der richtigen Reihenfolge enthält und welcher nur noch sequenziell in den Speicher geladen werden muß und von dort kann man dann ja
einen regulären Systemstart mit seinen vielen Abfragen, Wartezeiten, Verzweigungen usw. fortführen, aber
die wichtigsten Priozesse sollten erstmal in einem Rutsch in den Speicher geladen werden.
DAS würde den Systemstart wirklich beschleunigen, denn nichts ist so langsam wie die Festplatte und es hat ja nicht jeder eine SSD im Rechner.
* Der Cache oder Block würde beim ersten Start auf normale Weise wie bei einem normalen Systemstart generiert werden müssen.
Aber dannach wären alle Neustarts dann effizient und schnell und falls Fehler auftreten, dann generiert man den Cache oder Block neu.
Dann implementier das doch? Entweder ist das alles doch nicht so einfach, oder du wirst ein Held...
Gibts schon, nennt sich fcache. Hats aber wohl net gebracht ...
http://lkml.org/lkml/2006/5/15/46
Also ich finde die Idee sehr gut! Wenn ich gut genug programmieren koennte, wuerde ich das glaub ich machen
Ja ein Dateisystem das lernt in welcher Reihenfolge welche Dateien immer gelesen werden und auch schreib/lese Häufigkeiten misst und danach die Daten auf der Platte umordnet wäre halt super. Ist gar nicht so neu, die Idee. Und angeblich arbeitete Microsoft an so was (oder ist das schon in Windows 7? kA).
Du meinst jetzt aber nicht Superfetch?
Das legt einfach häufig genutzte Daten nach dem Start in den Arbeitsspeicher und das wars schon.
Fedora readahead macht so was Ähnliches. Es liest die Dateien in der Reihenfolge, wie sie physisch auf der Disk liegen.
Vermutlich ist der Effekt kleiner, als du denkst. Ob man es braucht, hängt davon ab, ob die Platte schon am Anschlag ist. Eine allgemeine Aussage kann ich dazu nicht machen. Ich weiß nur, dass es Debian und Ubuntu im Archiv haben, aber nicht vorinstallieren.
Wann baut endlich mal jemand eine Festplatte, bei der jede Spur ihren eigenen Schreib/Lesekopf hat? Die Seek-Zeit wäre dann nur noch von der Rotationsgeschwindigkeit abhängig und die Übertragungsrate astronomisch.
Vermutlich, weil die Spuren dann so gross sein muessten, dass du neben deiner Wohnung ein Festplattengehaeuse stehen haettest.
Eine Hundert oder Zweihundert-zoll Festplatte ... Da möcht ich aber nimmer in der Nähe sein wenn die mit 7200rpm läuft
Die braucht sie ja dann nicht mehr, unter 1000 würden ja locker reichen
Das macht dann aber die zugriffszeiten schlecht.
Naja, die könnte man dann auch gleich als Energiespeicher verwenden.
Damit wären unsere Energieprobleme gelöst.
Ich wäre dafür solche großen Festplatten in jedes Haus zu bauen.
Hallo Du,
Festplatten für den Systemstart haben wir jetzt. Ich bin fast sicher, dass mein nächster Rechner (ist wohl noch 1 Jahr weg) von einer SSD bootet, wo die Sequenz praktisch keine Reihenfolge mehr spielt.
Die relevanten Entwickler im Linux-Umfeld scheinen eh schon lange SSDs zu haben. Und es ist daher kein Zufall, wenn man liest, dass btrfs mit SSDs besser zurecht kommt.
Die Festplatten sind Archiv, etc. und hat mit dem Boot nicht mehr viel zu tun.
Dazu kommt, dass ich nur sehr selten boote und im Grunde nicht booten will.
Auf meinem Laptop funktionier das traumhaft. Ich habe ein Wortmann Laptop, dessen BIOS nur 1 Sekunde braucht und damit macht es einen über Monate Suspend to Disk nach dem anderen.
Und dennoch ist damit in ein paar Sekunden wieder online, mit Fenstern, die teilweise seit Monaten laufen.
Dazu liest er völlig sequentiell ein Image mit maximaler Geschwindigkeit. Seit ich (wegen KDE4) auf XFCE umstieg, ist es noch ein wenig besser, da das Image noch kleiner wurde und subjektiv nach dem Suspend wirklich alles da ist. Das sind nur ein paar Hundert MB und das schafft die Disk in ein paar Sekunden und eben völlig sequentiell.
Dazu muss man natürlich auch sagen, dass ich deshalb Speicher spare, indem ich unnötige Services wie avahi-daemon entferne.
Nett ist auch der "nodm" (apt-get install nodm; apt-get remove gdm kdm) der quasi Nichts kann ausser mich automatisch einloggen, Passwort fragt bei mir das BIOS ab.
Ich würde mir wünschen, dass mein Desktop auch den Suspend und Resume schafft. Damit hatte ich zwar bisher kein Glück, sollte es aber wohl mal wieder versuchen. Habe ich länger nicht versucht, und vielleicht spiele ich ja doch mal das BIOS Update auf. In jedem Fall kann es der nächste Rechner, den ich kaufe, wie gesagt noch ne Weile weg.
Ich finde das Problem ist nicht, dass booten lange dauert (was ja auch nicht stimmt). Das Problem ist doch, dass man überhaupt booten muss.
Das beliebeste Feature an KDE war bei mir immer das automatische "Session-Restore", wo die Dokumente sich wieder so öffnen, wie sie vorher waren. Also die Konsole-Tabs, etc.
Nur warum sollten die Terminals überhaupt neu starten? Warum sollte auch nur ein Detail meines Desktops sich ändern? Warum setzt man nicht einfach immer fort?
Auf Telefonen ist es ja auch schon so. Und mit Suspend to Disk zieht das Umwelt-Argument für die PCs auch nicht mehr.
Daher finde ich, dass der hier vorgeschlagene Dienst sinnvoll ist, weil er den CPU/Speicher Verbrauch zur Laufzeit reduziert und die Features harmoniert. Denn dass "at" anders als "cron" anders als "init.d" anders als "inittab" anders als "Autostart" anders als ... funktioniert, ist ja nur lästig.
Und die Hoffnung, dass dann der sshd oder auch eine Datenbank nur dann läuft, wenn ich ihn wirklich anspreche, wäre wirklich nett, einfach weil es den Speicherdruck noch weiter senken würde. Vielleicht integrieren solche Services sich dann mit einem solchen Dienst und sowas wird gemacht. Dass es heute schon ginge ist ja klar.
Aber schneller booten? Interessant, aber nicht zwingend ein so gravierendes Thema wie schnelles Fortsetzen sein sollte.
Gruss,
Kay
> Und die Hoffnung, dass dann der sshd oder auch eine Datenbank nur dann läuft, wenn ich ihn wirklich anspreche, wäre wirklich nett
Wenn du willst, daß sshd nur dann startet wenn du es ansprichst, dann kannst du schon heute sshd über inetd starten.
http://de.wikipedia.org/wiki/Inetd
Hallo,
wie ich meinte "Dass es heute schon ginge ist ja klar.", nur integrieren Distributionen es bisher nie in der Form. Vielleicht würde das dann besser.
Gruss,
Kay
Also bei Slackware ist inetd dabei und wird auch genutzt.
Wenn du es für sshd auch nutzen willst, dann mußt du das eben entsprechend einrichten.
Schwer ist es ja eigentlich nicht, ist ja nur ne Zeile in der Configurationsdatei.
Nein, das ist schlicht falsch. Die meiste Zeit fressen beim Boot nicht die Festplattenzugriffe. Die meiste Zeit wird in die serielle Initialisierung von Systemen und Geräten verbraucht. Die zu parallelisieren bringt am meisten. Schaue dir einfach nur den Bootprozess an und messe ihn mit geeigneten Tools. Das ist leicht messbar und ziemlich unbestritten.
Windows macht das so. Es kann auch Startdateien gezielt auf schnellere Medien umlagern, siehe ReadyBoost und Konsorten.
da hab ich aufgehört zu lesen
Jaja nur nichts neues
Was der Bauer nicht kennt frisst er nicht
Schon mal dran gedacht wieder Windows zu installieren? Kein paketmanagment, kein konstistentes System aber Hauptsache abwärtskompatibel bis zum Erbrechen damit man ja keinen DAU erschreckt
Ach komm... als gäbe es auch nur eine Linuxdistribution welche wirklich konsistent wäre.
> Ach komm... als gäbe es auch nur eine
> Linuxdistribution welche wirklich konsistent
> wäre.
Zeig mir EINE deren Paketmanagment inkonsistent wäre!
Und ja, bei einem OS + Software ist das so ziemlich das wichtigste. Ich fahre meine Fedora-Installation seit einigen Jahren unverändert auf dem dritten Rechner und zwar mit einem Haufen Developer-Tools und Serverdiensten die nicht mit 3 Klicks eingerichtet sind.
Klar muss man das System pflegen
Aber zeig mir doch eine Windows-Installation die ohne nennenswerte Probleme von einem Rechner auf einen völlig anderen umzieht und dabie auch noch ein Komplett-Upgrade macht
Ich kenne den Namen Poettering nicht und mir ist auch egal was er früher mal verbockt hat oder haben soll.
Ich nutze Linux +10 Jahre und lerne nach wie vor jeden Tag dazu.
Ich denke jeder engagierte Mensch - und gerade einer der privat an etwas baut, was etwas optimiert - versucht Fehler zu meiden und besser zu werden.
Das Projekt klingt grossartig, wenn der Austausch unter debian nicht allzu kompliziert sein wird, werde ich es testen.
Ich freu mich drauf!
/thorsten
P.S.
Danke für den tollen Artikel!
Ts... Ich finde die Kommentare auf Prolinux teils lustig teils auch irgendwo beschämend.
Wann immer ich die (trolligen?!) der und der ist Schlecht, oder dass und das ist total sch**** oder oh mein Gott der nicht lese, frage ich mich was für Erwartungen die Leute ham...
Falls jemand weiterlesen möchte, die nächsten Zeilen sind mein subjektiver Eindruck...
a) generell (und das betrifft auch Pulseaudio): Es ist nicht irgendein GUI Programm bei dem man Risiken und mögliche Fehlerquellen abschätzen und einfach ausloten kann (verschiedene Distributionen und distributionsspezifische Sachen, verschiedene Kernel, Treiberversionen, Desktopversionen, Kernelbuilds usw... ) Bei einem GUI Programm hat man, bis zu einer gewissen Komplexität, einen Überblick...
b) Pulseaudio hat vieles vereinfacht... Und dieses plattreden eines Projektes... Sorry, ich muss da immer an Erfahrungen im Kundenbereich denken, Lieblingsaussage: Ja ich hab ja gegooglet und einfach alles mögliche ausprobiert was da stand...Google ist toll Google ist mächtig, aber Google kann nicht prüfen welche Sachen sinnvoll sind oder nicht [Beispiel: Erstellung von Konfigurationsdateien, ala .asoundrc oder /etc/asound.conf ohne sich bewusst zu sein was es tut... Oder dass die nötigen alsa-plugins installiert sind...] Und dass ist es meistens... Oder aber das typische Probleme mit YouTube verses PA. Pulseaudio ist natürlich schlecht, weil Flash ja nur proprietär ist und ein Audiogerät blockiert. Aber PA ist böse!
c) Ohne eine große Quelle von Bugreports um auf die Komplexität von a eingehen zu können, ist es de fact unmöglich etwas zu verbessern. Und ich finde wenn man sich die Releases von Pulseaudio anschaut hat er meist nicht lange gefackelt falls gravierende Probleme existierten. ( hier sei der Hinweis gegeben: Bugfix ist ungleich Feature und Feature ist ungleich Bugfix. Verstehen auch einige Menschen nicht so ganz... )
d) Wenn ich bedenke dass viele Leute einfach nur das heulen anfangen und dann sagen der und der ist schuld, frag ich mich warum Sie es dann überhaupt tuen. Warum zieht ihr die jahrelange Arbeit, Debuggen, Fixen, releasen, Mailstress, private Zeit usw die ein Mensch investiert habt, in Frage? Wenn jemand tatsächlich seine Zeit so fehlinvestiert hätte, dann versteh ich nicht warum PulseAudio von vielen Leuten so gelobt wurde... (ich hatte nie Probleme, bis auf Flash und dass ist kein Problem im Sinne von PA) Und warum es dann auch noch in Distributionen eingesetzt wird, keine Ahnung. Scheinbar konsumieren alle Entwickler LSD und drücken wie wild doofe Knöpfe und es funktioniert [man beachte die IRONIE und den SARKASMUS... ]
Guter Kommentar. Stimme dir vollkommen zu.
Hm? Wo ist denn das Problem mit PA und Flash? Hier läuft das über das PA-Alsa-Plugin einwandfrei.
Sorry dass hätte ich bissel klarer schreiben sollen.
Dass Problem existiert nicht mehr bzw sollte nicht mehr existieren... Es war nur früher ein typisches Problem - und darauf bezog sich auch der Kommentar der fehlenden alsa-plugins...
Hatte mich etwas "überschlagen" in der Hinsicht
Aber genau dieses "Problem" brachte Leute dazu Pulseaudio zu hassen...
Amen!
Pulseaudio ist natürlich schlecht, weil Flash ja nur proprietär ist und ein Audiogerät blockiert. Aber PA ist böse!
Es kann doch nicht ernsthaft davon ausgegangen worden sein, man müsse alle Programme anpassen, damit sie mit PulseAudio funktionieren?
Wie kann überhaupt ein userspace Programm exklusiven Hardwarezugriff erlangen?
Das hat nichts mit exklusivem Hardwarezugriff zu tun. Eher damit, dass Steinzeit-Soundtreiber (und alles was in die Richtung geht) gleichzeitig nur ein einzelnes Programm bedienen können. Um mehrere Sounds gleichzeitig ausgeben zu können, bedarf es etwas modernerem Gerät...
Das sich das bis heute hält ist immer wieder erstaunlich.
Multiple Streams kann Alsa schon wie lange? 5 Jahre?
http://alsa.opensrc.org/index.php/Dmix
OSS kann das noch nicht so lange. Tragischerweise gibt es noch immer Anwendungen, die OSS benutzen bzw. nur damit richtig funktionieren.
> OSS kann das noch nicht so lange.
> Tragischerweise gibt es noch immer
> Anwendungen, die OSS benutzen bzw.
> nur damit richtig funktionieren.
Das ist dann aber Pech
Würden sie ALSA benutzen hättest du das Problem nicht und mit pulseaudio würden sie auch laufen
Installierte Pakete
Name : alsa-plugins-pulseaudio
Architektur : x86_64
Version : 1.0.22
Ausgabe : 1.fc12
Grösse : 93 k
Repo : installed
Aus repo : updates
Zusammenfassung : Alsa to PulseAudio backend
URL : http://www.alsa-project.org/
License : LGPLv2+
Beschreibung:This plugin allows any program that uses the ALSA API to access a PulseAudio
: sound daemon. In other words, native ALSA applications can play and record
: sound across a network. There are two plugins in the suite, one for PCM and
: one for mixer control.
Sorry, aber ich glaube du verkennst die Realität. In der Praxis sieht es so aus. das pulseaudio theoretisch fast alles kann. In der Praxis aber durch ein paar Grundsatzentscheidungen sich selbst ins Abseits befördert. Es resampled alles und Linux kann kein RT standardmässig. Wie gesagt die Designidee ist gut, die Ausführung mangelhaft. Warum will man alles resamplen/zusammenmixen in Software wenn man ebenso die Fähigkeiten der zugrundeliegenden Hardware ausloten könnte. Wenn es für ein bischen Gebimmel hier und etwas Geplärre da geht, aber versuche AC3, DTS oder ähnliches. Auch Musikhören macht mit Verzerrungen bei Last keinen Spass, ein simpler Voicechat braucht 30% CPU Leistung auf mittleren Systemen.
Die Leistung verkenne ich sicher nicht. In manchen Teilen hat er sogar Recht. Ich befürchte nur dass das wieder das rigide Umsetzen einer Theorie wird - die in der Praxis so nicht funktioniert.
Ja ich benutze fast 100% upstart und die Probleme die er beschreibt sind in der Tat so vorhanden. Bei der Hälfte aller Jobs die ich so geschrieben habe musste ich irgendwelche while schleifen einfügen die sicherstellen das der Dienst wirklich da ist. Ausserdem sind die Abhängigkeiten teilweise die Hölle wenn man etwas mehr versucht als nur einen Webserver zu starten.
Ich stimme dir 100% zu deinem Pulseaudio-kommentar zu!
"Warum will man alles resamplen/zusammenmixen in Software wenn man ebenso die Fähigkeiten der zugrundeliegenden Hardware ausloten könnte."
Macht Pulseaudio das auch (anscheinend "in Software"?), wenn Soundkarten wie SB Live oder SB Audigy vorhanden sind, die Hardware-Mixing beherrschen?
Nein, oder?