Lennart Poettering sollte lieber mal die ganzen Bugs von Pulse-Audio fixen und nicht andauernd alles umkrempeln wollen. So gut ist er nun auch wieder nicht. Die Forderungen sind nicht neu und jeder Administrator eines größeren Netzwerks kennt sie.
Das erste Probleme von Syslog ist, dass der Name des Programms vom Programm selbst gewählt werden kann. Die Lösung dazu sind die SCM_CREDENTIALS. Man müsste die glibc umschreiben, damit automatisch bei openlog diese mitgeschickt werden.
Das zweite Problem ist Teil der Anwendungen selbst. Viele Programmierer haben nicht die leiseste Ahnung, welche Meldungen welchen Schweregrad haben sollten. Heimdal zb. schickt ALLE Meldungen als error. Es ist echt sinnlos, darin nach wichtigen Meldungen zu suchen. Andere Anwendungen sind nicht besser. Der neue super-coole Ansatz wird das Problem nicht lösen. Der Text der Nachrichten ist oft vollkommen unverständlich für den Anwender. Oft wird auch gar nichts geloggt und das Programm funktioniert einfach wortlos nicht. Die besten Nachrichten sind die im Sinn von "ätsch, geht nicht!". Dieses Problem wird der neue Ansatz nicht lösen.
Das dritte Problem sind Nachrichten mit mehr als einer Zeile. Hier versagt Syslog in den meisten Fällen. Mit einem neuen Speicherformat allein kann das aber nicht gelöst werden. Man müsste im Protokoll zw. Anwendungen und lokalem Log-Server schon mehr als eine Zeile unterstützen.
Die UUID ist keine grundsätzlich schlechte Idee, es wird nur keiner umsetzen. Der Vorteil wäre, dass man leichter einzelne Nachrichten ignorieren kann. Günstig wäre eine eindeutige, zufällige UUID für jede einzelne Instanz einer Nachricht, sodass man mehrere zentrale Logserver ausfallssicher verwenden kann, ohne dass sich Nachrichten darin verdoppeln.
Dass man Logs echt microsekunden genau braucht, bezweifle ich.
Was mit "Meldungen werden in verschiedene Dateien geschrieben, was ihre Zuordnung schwierig macht" gemeint ist, weiß ich nicht. Zuordnung zu sich untereinander? Man hat ja einen Zeitstempel. Das sollte schon reichen. Ein besseres Format als reine Textdateien ist sicher sinnvoll. Dafür würde aber auch z.B. Sqlite reichen. Viele speichern Logs derzeit schon in SQL-Datenbanken.
Dass zwischen Nachrichten des Systems und solchen von Benutzerprogrammen nicht unterschieden wird, ist ein Problem. Die beste Lösung hier wäre ein ähnliches Modell wie DBus mit system und session bzw. wie bei libvirtd. Man könnte es recht hässlich lösen, indem openlog eine Umgebungsvariable prüft. Sind z.B. DISPLAY oder TERM gesetzt, geht man davon aus, dass es eher ein Programm ist, das Teil einer Benutzeranmeldung ist.
Das Rotieren anhand der Größe klappt, solange trotzdem auch anhand der Zeit rotiert werden kann. Gesetze bestimmen unter Umständen, wie lange welche Nachrichten aufbehalten werden dürfen bzw. müssen (auch hier kann die UUID helfen). Das ist leider nicht so einfach, aber auch im Sinne des Datenschutzes wichtig.
Alles in allem sind manche Ideen vielleicht ganz nett, aber nicht neu und schon gar nicht umsetzbar. Manche Kritikpunkte kommen sogar aus einer Zeit vor syslog-ng, rsyslog und co. Heutige Syslog-Server können schon mehr.
PulseAudio hatte eine lange Zeit viele Probleme gemacht. Das darf man durchaus noch heute erwähnen, vor allem wenn der Entwickler den halben Linuxuserspace umbauen will.
Allerdings sei angemerkt das ich ebenfalls kaum noch Probleme mit PulseAudio habe. Es wurde besser, keinen Zweifel. Schlimmer wäre aber auch kaum möglich gewesen
Vielleicht hat er einen Soundchip im Rechner, der mit Pulseaudio immer noch Probleme macht. Unter openSUSE z.B. sind Pulseaudioprobleme aber kein Weltuntergang, da man hier über das Yast-Sound-Modul ein installiertes Pulseaudio nach Belieben per Mausklick aktivieren oder deaktivieren kann. Das elende Herumgrutzen im Paketmanager (ich meine damit die manuelle Pulseaudiodeinstallation) und in irgendwelchen Soundkonfigurationsdateien entfällt somit.
Von cyberpatrol am Di, 22. November 2011 um 14:16 #
Ich sage nur ice1712. Mit diesen Karten kann PulseAudio noch immer nicht umgehen. Mal abgesehen davon, dass ich PulseAudio auch in jeglicher anderer Hinsicht für völlig überflüssig halte.
1. Realtime-Anwendung wie Proaudio-Software: Kann Jack mit Sicherheit besser. 2. Das Mischen der Soundausgaben verschiedener Programme: Kann ALSA schon lange out of the box. 3. Besagte ice1712-Audiokarten (nein, es sind keine Stereo-Soundkarten a la Soundblaster): Kann PulseAudio überhaupt nicht, ALSA dagegen out of the box. 4. PulseAudio kann meines Wissens nur von jeweils einem User gleichzeitig gestartet und genutzt werden. ALSA läuft global auf dem gesamten System und kann von jedem User gleichzeitig benutzt werden.
Was soll also bitteschön der Sinn von PulseAudio sein?
Mal abgesehen davon, dass es mir ziemlich auf den Senkel geht, dass sich dieser Poettering einbildet, alle seine eher weniger optimalen und schon gar nicht ausgereiften Ideen als Standards einführen lassen zu wollen. Leider wird dieses nicht funktionierende PulseAudio meines Wissens schon von diversen Distributionen und Desktop-Oberflächen (zumindest Gnome 3) zwingend vorausgesetzt.
Ich meine, von mir aus kann er entwickeln, was er will, solange es optional bleibt. Von mir aus kann er auch ständig halbfertiges Zeug bauen und auch von seinen anderen halbfertigen Sachen abhängig machen. Aber bitteschön optional und nicht als Quasi-Standard bezeichnen. Denn so ein Guru ist er nun wirklich nicht. Denn dann würde PulseAudio perfekt funktionieren und vor allem mit allen Sound- und Audiokarten perfekt umgehen können und zwar in einer Art, wie es von den Karten-Herstellern gemeint ist.
Da lob ich mir doch Arch Linux. Hier komme ich bisher noch an Poetterings Krempel vorbei, wenn ich nicht unbedingt will.
Meiner Meinung nach hat Poettering eher ein übersteigertes Geltungsbedürfnis. Warum kommt mir da nur auch immer wieder der Name eines gewissen Entwicklers einer gewissen Brenn-Software in den Kopf?
Poettering gab Prolinux irgendwann einmal ein Interview. Daraus ging hervor, dass Poettering natürlich weiß, dass einige Soundchips nicht mit Pulseaudio funktionieren.
Unter Debian Squeeze funktionierte auf einem Intel-Rechner mit AD1885-Soundchip übrigens Alsa nicht (Debian Lenny funktionierte noch damit). Ich bin dann notgedrungen zu OSS4 gewechselt, merkwürdigerweis ist der Sound so gut wie nie zuvor.
Was Poettering bei Red Hat so entwickelt, ist ganz im Sinne RedHats. Poettering gestaltet zur Zeit das Linux-Startsystem so um, dass es zwar objektiv "einfacher" wird, für Nichtprogrammierer bzw. entsprechend Ungeübte aber nicht mehr ohne Supportanfragen zu betreuen ist. Letztendlich wird es dadurch komplizierter.
OSS4 ist wirklich gut. Das war meine Alternative No. 1 als PulseAudio nicht ging. Dank fertiger Pakete für alle großen Distries war es in 5 Minuten eingerichtet.
Lennart Poettering sollte lieber mal die ganzen Bugs von Pulse-Audio fixen und nicht andauernd alles umkrempeln wollen. So gut ist er nun auch wieder nicht. Die Forderungen sind nicht neu und jeder Administrator eines größeren Netzwerks kennt sie.
Das erste Probleme von Syslog ist, dass der Name des Programms vom Programm selbst gewählt werden kann. Die Lösung dazu sind die SCM_CREDENTIALS. Man müsste die glibc umschreiben, damit automatisch bei openlog diese mitgeschickt werden.
Das zweite Problem ist Teil der Anwendungen selbst. Viele Programmierer haben nicht die leiseste Ahnung, welche Meldungen welchen Schweregrad haben sollten. Heimdal zb. schickt ALLE Meldungen als error. Es ist echt sinnlos, darin nach wichtigen Meldungen zu suchen. Andere Anwendungen sind nicht besser. Der neue super-coole Ansatz wird das Problem nicht lösen. Der Text der Nachrichten ist oft vollkommen unverständlich für den Anwender. Oft wird auch gar nichts geloggt und das Programm funktioniert einfach wortlos nicht. Die besten Nachrichten sind die im Sinn von "ätsch, geht nicht!". Dieses Problem wird der neue Ansatz nicht lösen.
Das dritte Problem sind Nachrichten mit mehr als einer Zeile. Hier versagt Syslog in den meisten Fällen. Mit einem neuen Speicherformat allein kann das aber nicht gelöst werden. Man müsste im Protokoll zw. Anwendungen und lokalem Log-Server schon mehr als eine Zeile unterstützen.
Die UUID ist keine grundsätzlich schlechte Idee, es wird nur keiner umsetzen. Der Vorteil wäre, dass man leichter einzelne Nachrichten ignorieren kann. Günstig wäre eine eindeutige, zufällige UUID für jede einzelne Instanz einer Nachricht, sodass man mehrere zentrale Logserver ausfallssicher verwenden kann, ohne dass sich Nachrichten darin verdoppeln.
Dass man Logs echt microsekunden genau braucht, bezweifle ich.
Was mit "Meldungen werden in verschiedene Dateien geschrieben, was ihre Zuordnung schwierig macht" gemeint ist, weiß ich nicht. Zuordnung zu sich untereinander? Man hat ja einen Zeitstempel. Das sollte schon reichen. Ein besseres Format als reine Textdateien ist sicher sinnvoll. Dafür würde aber auch z.B. Sqlite reichen. Viele speichern Logs derzeit schon in SQL-Datenbanken.
Dass zwischen Nachrichten des Systems und solchen von Benutzerprogrammen nicht unterschieden wird, ist ein Problem. Die beste Lösung hier wäre ein ähnliches Modell wie DBus mit system und session bzw. wie bei libvirtd. Man könnte es recht hässlich lösen, indem openlog eine Umgebungsvariable prüft. Sind z.B. DISPLAY oder TERM gesetzt, geht man davon aus, dass es eher ein Programm ist, das Teil einer Benutzeranmeldung ist.
Das Rotieren anhand der Größe klappt, solange trotzdem auch anhand der Zeit rotiert werden kann. Gesetze bestimmen unter Umständen, wie lange welche Nachrichten aufbehalten werden dürfen bzw. müssen (auch hier kann die UUID helfen). Das ist leider nicht so einfach, aber auch im Sinne des Datenschutzes wichtig.
Alles in allem sind manche Ideen vielleicht ganz nett, aber nicht neu und schon gar nicht umsetzbar. Manche Kritikpunkte kommen sogar aus einer Zeit vor syslog-ng, rsyslog und co. Heutige Syslog-Server können schon mehr.
Und der Zwang zu Systemd ist anmaßend. Das Design von Upstart ist dem von System überlegen.
Systemd wurde gerade deswegen gestartet, weil das Design von Upstart verkehrt ist.
"weil das Design von Upstart verkehrt ist."
Diese Meinung teilt keineswegs jeder.
Ja, die Macher von Upstart natürlich nicht, aber sonst teilt sie so ziemlich jeder.
"aber sonst teilt sie so ziemlich jeder."
Sicherlich nimmst es es so wahr, stimmen tut es jedoch deswegen nicht
Also mit PulseAudio hatte ich jetzt schon eine ganze Weile keine Probleme mehr.
Vorurteile sterben nie aus.
PulseAudio hatte eine lange Zeit viele Probleme gemacht. Das darf man durchaus noch heute erwähnen, vor allem wenn der Entwickler den halben Linuxuserspace umbauen will.
Allerdings sei angemerkt das ich ebenfalls kaum noch Probleme mit PulseAudio habe. Es wurde besser, keinen Zweifel. Schlimmer wäre aber auch kaum möglich gewesen
Vielleicht hat er einen Soundchip im Rechner, der mit Pulseaudio immer noch Probleme macht.
Unter openSUSE z.B. sind Pulseaudioprobleme aber kein Weltuntergang, da man hier über das Yast-Sound-Modul ein installiertes Pulseaudio nach Belieben per Mausklick aktivieren oder deaktivieren kann.
Das elende Herumgrutzen im Paketmanager (ich meine damit die manuelle Pulseaudiodeinstallation) und in irgendwelchen Soundkonfigurationsdateien entfällt somit.
Lieber Systemd als upstart - Seit der Hauptentwickler weg ist wird der immer langsamer...
Seit Fedora 15 (mit wenigen Anlauf-Schwierigkeiten was wohl eher an der defekten HDD lag als an Systemd) sehe ich einen wirklicken Leistungsschub...
Fedora 16 ist nun recht schnell im Start - Weiter so...
Ich sage nur ice1712. Mit diesen Karten kann PulseAudio noch immer nicht umgehen. Mal abgesehen davon, dass ich PulseAudio auch in jeglicher anderer Hinsicht für völlig überflüssig halte.
1. Realtime-Anwendung wie Proaudio-Software: Kann Jack mit Sicherheit besser.
2. Das Mischen der Soundausgaben verschiedener Programme: Kann ALSA schon lange out of the box.
3. Besagte ice1712-Audiokarten (nein, es sind keine Stereo-Soundkarten a la Soundblaster): Kann PulseAudio überhaupt nicht, ALSA dagegen out of the box.
4. PulseAudio kann meines Wissens nur von jeweils einem User gleichzeitig gestartet und genutzt werden. ALSA läuft global auf dem gesamten System und kann von jedem User gleichzeitig benutzt werden.
Was soll also bitteschön der Sinn von PulseAudio sein?
Mal abgesehen davon, dass es mir ziemlich auf den Senkel geht, dass sich dieser Poettering einbildet, alle seine eher weniger optimalen und schon gar nicht ausgereiften Ideen als Standards einführen lassen zu wollen. Leider wird dieses nicht funktionierende PulseAudio meines Wissens schon von diversen Distributionen und Desktop-Oberflächen (zumindest Gnome 3) zwingend vorausgesetzt.
Ich meine, von mir aus kann er entwickeln, was er will, solange es optional bleibt. Von mir aus kann er auch ständig halbfertiges Zeug bauen und auch von seinen anderen halbfertigen Sachen abhängig machen. Aber bitteschön optional und nicht als Quasi-Standard bezeichnen. Denn so ein Guru ist er nun wirklich nicht. Denn dann würde PulseAudio perfekt funktionieren und vor allem mit allen Sound- und Audiokarten perfekt umgehen können und zwar in einer Art, wie es von den Karten-Herstellern gemeint ist.
Da lob ich mir doch Arch Linux. Hier komme ich bisher noch an Poetterings Krempel vorbei, wenn ich nicht unbedingt will.
Meiner Meinung nach hat Poettering eher ein übersteigertes Geltungsbedürfnis. Warum kommt mir da nur auch immer wieder der Name eines gewissen Entwicklers einer gewissen Brenn-Software in den Kopf?
Poettering gab Prolinux irgendwann einmal ein Interview.
Daraus ging hervor, dass Poettering natürlich weiß, dass einige Soundchips nicht mit Pulseaudio funktionieren.
Unter Debian Squeeze funktionierte auf einem Intel-Rechner mit AD1885-Soundchip übrigens Alsa nicht (Debian Lenny funktionierte noch damit). Ich bin dann notgedrungen zu OSS4 gewechselt, merkwürdigerweis ist der Sound so gut wie nie zuvor.
Was Poettering bei Red Hat so entwickelt, ist ganz im Sinne RedHats. Poettering gestaltet zur Zeit das Linux-Startsystem so um, dass es zwar objektiv "einfacher" wird, für Nichtprogrammierer bzw. entsprechend Ungeübte aber nicht mehr ohne Supportanfragen zu betreuen ist. Letztendlich wird es dadurch komplizierter.
OSS4 ist wirklich gut. Das war meine Alternative No. 1 als PulseAudio nicht ging. Dank fertiger Pakete für alle großen Distries war es in 5 Minuten eingerichtet.