Mein erster Gedanke war: Linux+Systemd wird langsam zu einem fetten monolithischem Konstrukt ohne saubere Trennung der Verantwortlichkeiten, komplex und unwartbar.
Der zweite Gedanke war: Ja, die haben gute Ideen und Argumente. Sie scheinen ihr Handwerk zu verstehen und vermutlich sind die Zeiten vorbei, in denen Anwendungen auf (theoretisch) beliebigen UNIX-Systemen eingesetzt werden konnte. Linux+Systemd ist wohl bald die Grundlage für viele Anwendungen, GNOME3 war nur der Anfang. Und das ist auch gut so, man kann schließlich nicht ewig aus Rücksicht auf Kompatibilität mit exotischen Systemen die Entwicklung behindern.
Es ist sicher nicht verkehrt die Entwicklung mit gemischten Gefühlen zu verfolgen. Es kann etwas gutes daraus erwachsen, aber auch viel schaden anrichten.
Dabei ist für mich die Kompatibilität das eher geringere Problem, sind doch andere Unixsysteme heute kaum noch von Bedeutung, bzw. können sich durchaus an Linux annähern wenn notwendig. Der großflächige Austausch von Komponenten bedeutet jedoch nicht automatisch das danach alles besser wird. Neue Konzepte können und werden neue Probleme mit sich bringen, zudem werden viele bekannte und erprobte einfache Lösungen durch wesentlich komplexere ersetzt.
Vieles wird undurchsichtiger, manches wandelt sich von lesbaren Textdateien in Binärformate. Klare Trennungen werden aufgelöst.
Das sind keine reinen "früher kannte ich alles, heute nicht mehr" Probleme, ich glaube das die Ideen bei systemd auch dazu führen können das neue Linuxer weniger leicht in das System in die Tiefe einsteigen können.
Aber man wird sehen, möglicherweise ist die Umstellung schmerzfreier als ich es erwarte. Wenn ich bedenke das ich schon eine ganze weile keinen Kernel mehr kompiliert habe... vielleicht schreitet die Abstraktion ohne schaden weiter voran, und man benötigt nicht mehr auf alles leichtesten direkten Zugriff, da die Lösungen tatsächlich den Bedarf der Anwender von Haus aus besser entsprechen.
Ja, da gebe ich dir Recht, sie müssen in der Tat aufpassen, dass die Geschichte nicht unnötig komplex wird. Aber der Artikel hat mich in dieser Richtung eher beruhigt:
An erster Stelle steht die Einfachheit, die wohl den größten Vorteil des aktuellen Syslog darstellt. Der Code soll so klein wie möglich sein, wenige Abhängigkeiten enthalten (Systemd wird allerdings vorausgesetzt) und keine Abstraktionen enthalten.
Es soll robust sein und die Daten sollen sich leicht auf andere Systeme kopieren und dort lesen lassen. Es soll auf alle Linux-Systeme portierbar sein, [...].
Syslog wird parallel dazu weiterlaufen, da es geraume Zeit dauern wird, alle bisherigen Logs zu ersetzen.
Letzterer Punkt ist meiner Ansicht nach sehr wichtig, um eine schrittweise und somit reibungslose Migration zu ermögichen.
btw: Ich kompiliere relativ häufig den Linux Kernel selbst, da ich Gentoo benutze. Ist aber heutzutage super unproblematisch und ein halbwegs erfahrener Linux-Benutzer blickt da schnell durch und kann falls nötig selbst dran rumpatchen.
Bei grub2 kann man sehen, wie es nicht laufen sollte
Wer kann denn da heute "noch mal eben" die Config bearbeiten, wenn es um Setups wie /boot auf Soft-RAID und / auf LVM auf Soft-RAID geht. Da blickt doch keiner mehr durch bei den Config-Dateien.
Vielleicht sollte der Lennart Poettering mal einen Bootloader schreiben
Grub2 ist für den DAU gemacht. Es geht explizit darum, die Konfigurierbarkeit zu mindern. Es ist der Gnom3-Ansatz. Die Programmierer wissen, was der Benutzer will.
Ich sehe das anders. Letztendlich richtet sich Grub2 "gegen" Normalnutzer und Sysadmins. Es ist kaum möglich, einen Bootloader mit mehr unnötigem Konfigurationsoverkill zu entwickeln als Grub2. Grub2 ist in dieser Hinsicht so schlecht, dass Fedora erst quasi im letzten Moment und openSUSE bis heute nicht zu Grub2 als Standardbootloader gewechselt sind.
Wenn man in der FAQ nachschaut, dann findet man dort diese merkwürdige Bemerkung, die meine schlimmsten Befürchtungen bestätigt:
"Will the journal file format be standardized? Where can I find an explanation of the on-disk data structures?
At this point we have no intention to standardize the format and we take the liberty to alter it as we see fit. We might document the on-disk format eventually, but at this point we don’t want any other software to read, write or manipulate our journal files directly. The access is granted by a shared library and a command line tool. (But then again, it’s Free Software, so you can always read the source code!)"
Grub allgemein ist ein gutes Beispiel, für beide Fälle.
Ich habe viel direkt mit LiLo gemacht, musste man ja auch. Ich hatte es andauernt anpacken müssen, rückblickend weiß ich aber kaum noch warum.
Schon mit Grub 0.x verstand ich manches nicht mehr, der Ablauf war ungewohnt, vieles neu. Aber ich merkte auch schnell das ich es auch kaum noch anpassen musste, auch weil die Tools der Distributionen schnell besser wurden.
Grub ist mächtiger als LiLo, keine Frage, aber ich kann damit persönlich weniger machen. Gleichzeitig nervt er mich aber auch weniger, zumindest aktuell.
Solange ich nicht näher ran muss, und mir dann vielleicht eine blutige Nase hole, bin ich momentan zufrieden damit.
Sicherlich, allerdings gibt es genug GNOME Apps denen installierte GNOME-Libs genügen, soweit ich es sehe ist dieses Tool tief in KDE (durch das Kontrollzentrum, soweit ich das Tool verstehe) eingebettet, so wie ich es sehe startet das halbe KDE im Background wenn man dieses Tool nutzen will. Ich wäre positiv überrascht wenn es nicht so wäre, meine Erfahrungen mit KDE sind aber doch anders.
Zudem könnte man durchaus so ein Tool auch ganz ohne Abhängigkeiten bauen. Gut, das ist heute selten, aber möglich.
Laut AUR https://aur.archlinux.org/packages/gr/grub2-editor/PKGBUILD hängt es von kdebase-workspace ab und da hängt nicht viel KDE dran (nur kde-pim), siehe http://www.archlinux.org/packages/extra/i686/kdebase-workspace/.
>sind doch andere Unixsysteme heute kaum noch von Bedeutung, bzw. können sich durchaus an Linux annähern wenn notwendig andere Betriebssysteme haben heute kaum noch Bedeutung, bzw. koennen sich an Windows anpassen. Das hatten wir schon mal... - nein danke! Monokultur - egal von welcher Seite - krankt!
zu journald: - nicht portabel (s.o.) - wozu eine abhaengigkeit von systemd. ungeachtet dessen ob systemd was taugt oder nicht. wo bleibt die gute alte unix-philosophie: lauter kleine tools, die man prima kombinieren kann. wenn linux da nicht wieder hin zurueckkehrt, schaufelt es sich sein eigenes grab, denn ein monolitisches system haben wir schon von microsoft. - inkompatibilitaet schon im design: ein binaerformat das sich von version zu version aendern kann. also hab ich 10 systeme und brauch nachher 10 verschiedene tools um die log files auszuwerten. - na glueckwunsch - kein loggen ueber netzwerk. ein extrem wichtiges feature wenn man groessere netzwerke verwalten will. und letztlich (fast) die einzige moeglichkeit sicherzustellen, dass die logfiles nicht modifiziert werden. die idee mit den hash's ist ja ganz nett, aber nicht wirklich praxistauglich. erstens setzt es ein read-only medium vorraus zur hash-verwaltung, alleine daran duerfte es in den meisten faellen scheitern. aber selbst wenn es vorhanden ist, hindert das einen angreifer nicht die logfiles zu veaendern oder zu loeschen. das faellt zwar auf (vorrausgesetzt jemand achtet drauf), aber das einzigste was man daraus erkennt, ist das ein angriff stattgefunden hat (oder vielleicht doch ein software bug, oder statistischer bit-kipp?), aber mehr informationen erhaelt man nicht. - unflexibel. wenn man schon was neuen schafft, warum dann so unflexibel. warum nicht mehrere moegliche backends. eines um in files zu schreiben, eines zum schreiben in db, ... - ein nebeneinander von syslogd und journald ist zwar ganz nett, aber warum nicht gleich eine backward kompatibiltaet? warum zwei parallelwelten?
fazit: zwar ganz gute ansaetze, aber die umsetzung ist mangelhaft. aber warten wir mal ab, vielleicht reift journald ja noch, und in ein paar jahren, ...
"Also for the inclusion of new technologies we should not wait for the non-Linux to catch up or do sacrifices in order to still support non-Linux. If a new technology brings us great advantages on Linux but means we have to stop supporting non-Linux because they do not provide the technology, I think it’s better to be really good on the one system."
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.
Mein erster Gedanke war: Linux+Systemd wird langsam zu einem fetten monolithischem Konstrukt ohne saubere Trennung der Verantwortlichkeiten, komplex und unwartbar.
Der zweite Gedanke war: Ja, die haben gute Ideen und Argumente. Sie scheinen ihr Handwerk zu verstehen und vermutlich sind die Zeiten vorbei, in denen Anwendungen auf (theoretisch) beliebigen UNIX-Systemen eingesetzt werden konnte. Linux+Systemd ist wohl bald die Grundlage für viele Anwendungen, GNOME3 war nur der Anfang. Und das ist auch gut so, man kann schließlich nicht ewig aus Rücksicht auf Kompatibilität mit exotischen Systemen die Entwicklung behindern.
Es ist sicher nicht verkehrt die Entwicklung mit gemischten Gefühlen zu verfolgen. Es kann etwas gutes daraus erwachsen, aber auch viel schaden anrichten.
Dabei ist für mich die Kompatibilität das eher geringere Problem, sind doch andere Unixsysteme heute kaum noch von Bedeutung, bzw. können sich durchaus an Linux annähern wenn notwendig.
Der großflächige Austausch von Komponenten bedeutet jedoch nicht automatisch das danach alles besser wird. Neue Konzepte können und werden neue Probleme mit sich bringen, zudem werden viele bekannte und erprobte einfache Lösungen durch wesentlich komplexere ersetzt.
Vieles wird undurchsichtiger, manches wandelt sich von lesbaren Textdateien in Binärformate. Klare Trennungen werden aufgelöst.
Das sind keine reinen "früher kannte ich alles, heute nicht mehr" Probleme, ich glaube das die Ideen bei systemd auch dazu führen können das neue Linuxer weniger leicht in das System in die Tiefe einsteigen können.
Aber man wird sehen, möglicherweise ist die Umstellung schmerzfreier als ich es erwarte.
Wenn ich bedenke das ich schon eine ganze weile keinen Kernel mehr kompiliert habe... vielleicht schreitet die Abstraktion ohne schaden weiter voran, und man benötigt nicht mehr auf alles leichtesten direkten Zugriff, da die Lösungen tatsächlich den Bedarf der Anwender von Haus aus besser entsprechen.
Ja, da gebe ich dir Recht, sie müssen in der Tat aufpassen, dass die Geschichte nicht unnötig komplex wird. Aber der Artikel hat mich in dieser Richtung eher beruhigt:
Letzterer Punkt ist meiner Ansicht nach sehr wichtig, um eine schrittweise und somit reibungslose Migration zu ermögichen.
btw: Ich kompiliere relativ häufig den Linux Kernel selbst, da ich Gentoo benutze. Ist aber heutzutage super unproblematisch und ein halbwegs erfahrener Linux-Benutzer blickt da schnell durch und kann falls nötig selbst dran rumpatchen.
Bei grub2 kann man sehen, wie es nicht laufen sollte
Wer kann denn da heute "noch mal eben" die Config bearbeiten, wenn es um Setups wie /boot auf Soft-RAID und / auf LVM auf Soft-RAID geht. Da blickt doch keiner mehr durch bei den Config-Dateien.
Vielleicht sollte der Lennart Poettering mal einen Bootloader schreiben
Grub2 ist für den DAU gemacht. Es geht explizit darum, die Konfigurierbarkeit zu mindern. Es ist der Gnom3-Ansatz. Die Programmierer wissen, was der Benutzer will.
Ich sehe das anders.
Letztendlich richtet sich Grub2 "gegen" Normalnutzer und Sysadmins.
Es ist kaum möglich, einen Bootloader mit mehr unnötigem Konfigurationsoverkill zu entwickeln als Grub2.
Grub2 ist in dieser Hinsicht so schlecht, dass Fedora erst quasi im letzten Moment und openSUSE bis heute nicht zu Grub2 als Standardbootloader gewechselt sind.
Wie sagte man damals schon, jedes GNU Projekt entwickelt sich früher oder später zu einem eigenen Betriebssystem.
Wenn man in der FAQ nachschaut, dann findet man dort diese merkwürdige Bemerkung, die meine schlimmsten Befürchtungen bestätigt:
"Will the journal file format be standardized? Where can I find an explanation of the on-disk data structures?
At this point we have no intention to standardize the format and we take the liberty to alter it as we see fit. We might document the on-disk format eventually, but at this point we don’t want any other software to read, write or manipulate our journal files directly. The access is granted by a shared library and a command line tool. (But then again, it’s Free Software, so you can always read the source code!)"
zitiert aus:
https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs
Behaltet es einfach.
Mir ist völlig klar, was Ihr bzw. Red Hat vorha(b)t.
Grub allgemein ist ein gutes Beispiel, für beide Fälle.
Ich habe viel direkt mit LiLo gemacht, musste man ja auch. Ich hatte es andauernt anpacken müssen, rückblickend weiß ich aber kaum noch warum.
Schon mit Grub 0.x verstand ich manches nicht mehr, der Ablauf war ungewohnt, vieles neu. Aber ich merkte auch schnell das ich es auch kaum noch anpassen musste, auch weil die Tools der Distributionen schnell besser wurden.
Grub ist mächtiger als LiLo, keine Frage, aber ich kann damit persönlich weniger machen. Gleichzeitig nervt er mich aber auch weniger, zumindest aktuell.
Solange ich nicht näher ran muss, und mir dann vielleicht eine blutige Nase hole, bin ich momentan zufrieden damit.
Man kann mit Bootloadern nichts falsch machen. Im schlimmsten Fall muss man halt von USB-Stick oder CDROM booten und den Bootloader wiederherstellen.
Was nichts desto weniger ziemlich nerven kann
Du könntest ihn in deine Windows C: Partition installieren. :)
Es gibt ein Konfigurations-Werkzeug für Grub2, dass "für den DAU" noch weit komfortabler ist, als die von Grub1.
Das Beste: es ist unabhängig von der Distro (man höre und staune!): http://kde-apps.org/content/show.php/GRUB2+Bootloader+Editor?content=139643
Sehe ich es richtig das dieses Tool nur mit installiertem KDE funktioniert?
Ja, scheint so und gnome-Tools funktionieren auch nur mit installierten Gnome-Libs. Welche Überraschung...
Sicherlich, allerdings gibt es genug GNOME Apps denen installierte GNOME-Libs genügen, soweit ich es sehe ist dieses Tool tief in KDE (durch das Kontrollzentrum, soweit ich das Tool verstehe) eingebettet, so wie ich es sehe startet das halbe KDE im Background wenn man dieses Tool nutzen will.
Ich wäre positiv überrascht wenn es nicht so wäre, meine Erfahrungen mit KDE sind aber doch anders.
Zudem könnte man durchaus so ein Tool auch ganz ohne Abhängigkeiten bauen. Gut, das ist heute selten, aber möglich.
Laut AUR https://aur.archlinux.org/packages/gr/grub2-editor/PKGBUILD hängt es von kdebase-workspace ab und da hängt nicht viel KDE dran (nur kde-pim), siehe http://www.archlinux.org/packages/extra/i686/kdebase-workspace/.
Ja, scheint so und gnome-Tools funktionieren auch nur mit installierten Gnome-Libs. Welche Überraschung...
für ubuntu gibts ein sehr gutes programm um grub2 unter gnome etc. spielend leicht zu konfigurieren: ppa:danielrichter2007/grub-customizer .
:up:
>sind doch andere Unixsysteme heute kaum noch von Bedeutung, bzw. können sich durchaus an Linux annähern wenn notwendig
andere Betriebssysteme haben heute kaum noch Bedeutung, bzw. koennen sich an Windows anpassen.
Das hatten wir schon mal... - nein danke!
Monokultur - egal von welcher Seite - krankt!
zu journald:
- nicht portabel (s.o.)
- wozu eine abhaengigkeit von systemd. ungeachtet dessen ob systemd was taugt oder nicht. wo bleibt die gute alte unix-philosophie: lauter kleine tools, die man prima kombinieren kann. wenn linux da nicht wieder hin zurueckkehrt, schaufelt es sich sein eigenes grab, denn ein monolitisches system haben wir schon von microsoft.
- inkompatibilitaet schon im design: ein binaerformat das sich von version zu version aendern kann. also hab ich 10 systeme und brauch nachher 10 verschiedene tools um die log files auszuwerten. - na glueckwunsch
- kein loggen ueber netzwerk. ein extrem wichtiges feature wenn man groessere netzwerke verwalten will. und letztlich (fast) die einzige moeglichkeit sicherzustellen, dass die logfiles nicht modifiziert werden. die idee mit den hash's ist ja ganz nett, aber nicht wirklich praxistauglich. erstens setzt es ein read-only medium vorraus zur hash-verwaltung, alleine daran duerfte es in den meisten faellen scheitern. aber selbst wenn es vorhanden ist, hindert das einen angreifer nicht die logfiles zu veaendern oder zu loeschen. das faellt zwar auf (vorrausgesetzt jemand achtet drauf), aber das einzigste was man daraus erkennt, ist das ein angriff stattgefunden hat (oder vielleicht doch ein software bug, oder statistischer bit-kipp?), aber mehr informationen erhaelt man nicht.
- unflexibel. wenn man schon was neuen schafft, warum dann so unflexibel. warum nicht mehrere moegliche backends. eines um in files zu schreiben, eines zum schreiben in db, ...
- ein nebeneinander von syslogd und journald ist zwar ganz nett, aber warum nicht gleich eine backward kompatibiltaet? warum zwei parallelwelten?
fazit: zwar ganz gute ansaetze, aber die umsetzung ist mangelhaft. aber warten wir mal ab, vielleicht reift journald ja noch, und in ein paar jahren, ...
Was hat GNOME 3 damit zutun?
Der Standard - Linux-only? GNOMEOS: Vom Desktop zum Betriebssystem?
Oh man...
Wieso? Das ist ziemlich sinnvoll und vernünftig. In der KDE-Community gibt es ähnliche Überlegungen: Thoughts about KDE Plasma on non-Linux Systems
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.