# Unbeliebte Software

## schmidicom

Nach einer eingehenden Begutachtung einiger Dinge die unter Gnome (aber auch anderen Denktopumgebungen) so als Abhängigkeiten mit installiert werden ist mir doch so einiges aufgefallen was ich als ziemlich unschön empfinde. Und nach einer Google-Suche zum besseren Verständnis ist dieses ungute Gefühl meist noch intensiver geworden. Die Rede ist von diversen Softwarepaketen die einen ziemlich fragwürdigen Eindruck hinterlassen (zumindest bei mir) und von denen ich hier einige ansprechen möchte.

dconf/gconf (ein gutes Versteck ist Gold wert)

Im Internet wird dies oft Liebevoll als "Registry ala Windoof" bezeichnet und gemäss meinen eigenen Erfahrungen ist das gar nicht mal so weit hergeholt. Dazu scheint das Ding noch nicht mal wirklich fertig zu sein, denn versucht man innerhalb von dconf oder gconf einen Systemweiten Parameter zu verändern wird man höflich darauf hingewiesen das diese Funktion noch nicht zur Verfügung steht. Dummerweise scheint das schon länger der Fall zu sein wodurch der Verdacht aufkommt das dies nie kommen wird. Ich will ja keinem auf die Füsse treten aber wieso äfft hier Linux etwas nach was bereits unter Windows zahllose (überwiegend erfahrene) Anwender oft genug in den Wahnsinn treibt?

gvfs (ich mach was ich will)

Auch das ist so eine Software die manchmal den Eindruck erweckt nicht ganz fertig zu sein. Zum einen macht sie was sie will und lässt sich kaum etwas sagen ausser man wühlt sich durch Berge von Dokus (die meisten davon natürlich nur in Englisch) und zum anderen scheint diese oft auch ein kleines Problem mit der Idee des Papierkorbes zu haben. Wodurch sich einem immer wieder die Frage aufgedrängt "Geht das nicht auch einfacher? Und überhaupt wozu gibt es /media wenn letzten Endes doch alles wieder ganz wo anders landet?", zumindest geht es mir so und laut Google scheinbar auch ein paar anderen.

policykit (du darfst das nicht aber ich auch nicht)

Es gab noch Zeiten da wurde noch durch die Benutzergruppe entschieden wer was darf doch nun scheint das nicht mehr zu reichen, doch wer darf nun was und wo einstellen. Obwohl das korrekte konfigurieren von Policykit mit Hilfe von diversen regeln (deren Schreibweise meistens erst eingehend erforscht werden muss) als machbar bezeichnet werden kann ist es im Vergleich zu den Unixgruppen schon fast eine Lebensaufgabe. Des Resultat sieht dann meistens so aus das letzten Endes jeder alles darf weil es dafür gerade mal zwei bis drei Zeilen Text braucht und somit auch kaum Zeit.

Mich würde interessieren wie ihr so darüber denkt und ob ihr noch weitere Kandidaten habt die man hier hinzufügen könnte.Last edited by schmidicom on Fri Jan 20, 2012 6:43 am; edited 1 time in total

----------

## mv

++

dconf und gvfs sind der Grund, weshalb ich auf etliche Gnome-Anwendungen verzichte. Auf KDE-Seite gibt es dafür das missglückte dbus-Konzept. Womit wir beim Thema wären:

systemd, avahi, policykit, consolekit, pulseaudio, und wie die anderen Fehlkonzeptionen von Lennart Poettering alle heißen: Alles Negativbeispiele, von denen man in einem guten Programmierkurs lernen sollte, dass man es so gerade nicht machen sollte. (Bei hal hat er es ja immerhin selbst eingesehen).

Bei KDE4 (und vermutlich ähnlich bei Gnome3 oder Unity) gibt es natürlich auch schlimme Unfälle, weil die auch aus Datenschutzgründen mehr als bedenklich sind: nepomuk, strigi, mysql. 

Eine Datenbank wie mysql ist per se noch nicht schlecht (wenngleich es da speziell bei mysql auch verschiedene Ansichten gibt), aber die Fehlkonzeption besteht hier darin, alles auf Teufel-komm-raus in einer Datenbank speichern zu wollen, mit den ganzen Problemen, die dies mit sich bringt (Verlust aller Daten bei kleinen Fehlern möglich, nicht-lesbares Format,  ev. Kompatibilitätsprobleme bei verschiedenen Architekturen, händisches Mergen oder Isolieren von Daten schwierig, usw. usf.).

----------

## franzf

 *mv wrote:*   

> Auf KDE-Seite gibt es dafür das missglückte dbus-Konzept.

 

dbus stammt nicht von kde, sondern von gnome (resp. freedesktop, k.A. wie man da trennt). kde hatte früher als eigenes System dcop, was später zugunsten eines einheitlichen Interfaces über die Desktops hinweg gegen dbus ausgetauscht wurde.

 *Quote:*   

> nepomuk, strigi, mysql.

 

Warum strigi? Das ist eigentlich nur ein System, um Metadaten aus Dateien zu extrahieren. Man kann zum Speichern ein Backend einhängen, ist aber nicht notwendig. strigi liefert z.B. zwei völlig unverwerfliche Tools zum Suchen in z.B. Binärdateien mit: deepfind und deepgrep

----------

## mv

 *franzf wrote:*   

>  *mv wrote:*   Auf KDE-Seite gibt es dafür das missglückte dbus-Konzept. 
> 
> dbus stammt nicht von kde, sondern von gnome (resp. freedesktop, k.A. wie man da trennt).

 

Ich hatte in Erinnerung, dass gnome ein System hatte, bei dem Programme schnell binär statt über den xml-Umweg miteinander kommunizierten. Aber ich kann falsch liegen.

 *Quote:*   

>  *Quote:*   nepomuk, strigi, mysql. Warum strigi? Das ist eigentlich nur ein System, um Metadaten aus Dateien zu extrahieren.

 

Ja, hier gilt Ähnliches wie bei mysql: strigi ist nicht per se das Problem, sondern eher die Art, wie es benutzt wird, also nepomuk. (Aber bei KDE offensichtlich nicht nur von nepomuk, denn obwohl ich nur ein Schmalspur-KDE ohne nepomuk benutze, kann ich strigi nicht loswerden). Und ähnlich wie bei mysql gilt für strigi, dass es anscheinend bessere Implementierungen für eine vergleichbare Aufgabe gäbe: recoll bzw. postgresql (und weshalb reicht sqlite nicht?)

----------

## schmidicom

Gleich zwei hochrangige die ähnliche Ansichten vertreten, ich bin zugegebenermassen positiv überrascht. Ich dachte schon ich wäre hier in der Gentoo-Gemeine der einzige (oder zumindest einer von sehr wenigen unbedeutenden) User dem/denen das alles langsam aber sicher schlicht und einfach zu wieder ist.

 *mv wrote:*   

> pulseaudio,

 

Ja das ist auch so ein Kandidat der bei mir in die Kategorie "Nett gemeint aber völlig überflüssig" fällt. Dumm nur das ohne ihn die meisten Desktopumgebungen von Haus aus keinen Lautstärkeregler mehr haben. Schon amüsant wie einen die Grossen mit Kleinigkeiten dazu bringen jeden noch so grossen .... zu installieren, den genau genommen weiss ich bis heute nicht was mir ein soundserver an mehr nutzen bringt abgesehen vom eben erwähnten Lautstärkeregler.

PS: Ich versuche gerade einen KDE-Desktop zum laufen zu bringen mit möglichst wenig von dem oben erwähnten, mal sehen wie dieses Experiment ausgeht.

----------

## ChrisJumper

Vorweg, ich habe nicht viel Ahnung von den angesprochenen Programmen sondern immer nur ein wenig Zeit über die Jahre damit Verbraucht die linux-magazin-Artikel dazu zu lesen.

In erster Linie sind das Teil-Strukturen die dem unerfahrenen Anwender das Leben leichter machen sollen. Ich würde auch sehr gerne darauf verzichten und bin froh das sich wenigstens die Gentoo-E-Build-Maintainer noch damit für die Use-Flags auseinander setzen.

Hin und wieder, je nach Anforderungen. Ist eine Zeroconf-Umgebung schon ganz praktisch. Pulseaudio ist bei einem kleinen Problem bestimmt ein mit Kanonen auf "Spatzen" schießen. Aber ich mag gar nicht mehr dran denken wie oft ich mich darüber geärgert hab das verschiedene Anwendungen den selben Sound-Regler haben. Wahrscheinlich ist das Beispiel unangebracht weil Pulseaudio das noch nicht mal löst.

GConf finde ich selber eigentlich ganz praktisch. Bei dem was ich bisher gesehen hab, kann es auf einem Mehrbenutzer-System die Einstellungen für jeden einzelnen gut verwalten. Aber das mag auch daran liegen das ich mich als Gnome-Nutzer daran gewöhnt hab, wenn ich eine Einstellung nicht in einem Menü finde, das sie ganz bestimmt (versteckt) in der Gconf auftaucht.

Für mich ist der gconf-editor einfach die Zentrale Stelle für diese Einstellungen. Das hätte man natürlich auch in Konfigurations-Dateien anlegen können, aber mit einem gewissen Umfang wäre diese bestimmt unübersichtlicher.

----------

## schmidicom

 *ChrisJumper wrote:*   

> Pulseaudio ist bei einem kleinen Problem bestimmt ein mit Kanonen auf "Spatzen" schießen. Aber ich mag gar nicht mehr dran denken wie oft ich mich darüber geärgert hab das verschiedene Anwendungen den selben Sound-Regler haben. Wahrscheinlich ist das Beispiel unangebracht weil Pulseaudio das noch nicht mal löst.

 

Ich vermute du meinst damit die Möglichkeit jedes Programm das mit Pulseaudio zusammenarbeitet (was auch nicht alle machen und infolge dessen zu weiteren Problemen führen kann) einzeln in der Lautstärke zu regeln ohne dabei die restlichen zu beeinflussen.

Das selbe gibt es auch unter Windows (ab Vista) und ich habe bis jetzt noch keinen User gesehen der das wirklich nutzt weder unter Windows noch unter Linux weil viele Programme wie Spiele oder Media-Player meist einen eigenen Regler bereits integriert haben. 

 *ChrisJumper wrote:*   

> GConf finde ich selber eigentlich ganz praktisch. Bei dem was ich bisher gesehen hab, kann es auf einem Mehrbenutzer-System die Einstellungen für jeden einzelnen gut verwalten. Aber das mag auch daran liegen das ich mich als Gnome-Nutzer daran gewöhnt hab, wenn ich eine Einstellung nicht in einem Menü finde, das sie ganz bestimmt (versteckt) in der Gconf auftaucht.
> 
> Für mich ist der gconf-editor einfach die Zentrale Stelle für diese Einstellungen. Das hätte man natürlich auch in Konfigurations-Dateien anlegen können, aber mit einem gewissen Umfang wäre diese bestimmt unübersichtlicher.

 

Das ist aber genau das Problem an der ganzen Geschichte mit dconf/gconf, die Programmierer verlagern immer mehr von der UI in dieses System weil die UI ja möglichst "einfach" sein soll. Das dadurch aber auch die Übersicht und Kontrolle der möglichen Einstellungen verloren geht wird dabei gekonnt übersehen. Klar findet man innerhalb von dconf/gconf alles aber nur wenn man genau weiss wonach man suchen muss und das ist ohne Google-Suche nicht mehr der Fall. Darüber hinaus scheinen einige Optionen die eigentlich nur für den einen Desktop gedacht sind sich auch auf andere Desktopumgebungen aus zu wirken wie das jüngste Beispiel mit dem Automount von Nautilus zeigt (siehe unten). Selbst der regedit von Windows ist ausgereifter als der Editor von dconf/gconf, im regedit kann man auch globale Einstellungen anpassen (sofern die persönlichen Rechte dies erlauben) doch bei dconf/gconf geht das nicht mal unter root. Aber auch unter Windows regt sich bei einigen widerstand gegen diese registry weshalb viele Programme (TeamSpeak 3, ZOC Termianl, ...) ihre Einstellungen wieder in *.ini Dateien speichern. Die Idee einer zentralen Anlaufstelle für Einstellungen ist zwar nicht schlecht aber die Umsetzung dergleichen ist meiner Meinung nach eine einzige Katastrophe.

Beispiel Automount dank dconf/gconf und Nautilus in KDE und anderen:

Nautilus hat innerhalb von dconf/gconf eine Einstellung die dafür sorgt das alle angeschlossenen USB-Datenträger automatisch gemountet werden (die erst seit kurzen Standardmässig aktiviert ist) aber die dazugehörige Option in den Systemeinstellungen unter Gnome zur Deaktivierung fehlt. Jeder Benutzer muss einzeln für sich erst mal innerhalb von dconf/gconf auf die Suche nach dieser Einstellung gehen wenn dieses Verhalten gestoppt werden soll.

----------

## mv

 *ChrisJumper wrote:*   

> In erster Linie sind das Teil-Strukturen die dem unerfahrenen Anwender das Leben leichter machen sollen.

 

So wie das grundsätzliche Arbeiten als "Administrator" unter Windows dem unerfahrenen Anwender das Leben leichter machen soll - und den Autoren von Viren und anderer Schadsoftware.   :Wink: 

Ernsthafter: Das Problem ist nicht, dass dies geschieht, sondern, dass dies auf eine für Unix-Systeme völlig inadäquate Weise geschieht.

Beispiel consolekit und policykit: Für Desktopumgebungen ist es durchaus zweckmäßig, dass der eingeloggte Benutzer "registriert" wird und zusätzliche Rechte bekommt. Dazu gibt es aber vorgehesene Mechanismen: Registrieren sollte in einer Datei in /var/run (oder einen ähnlichen Pfad) passieren, nicht durch einen ständig laufenden Dämon, der permanent Resourcen frisst, und auch sonst nur Nachteile hat. Beim Einloggen können dann auch die Rechte der Laufwerke entsprechend auf den User gesetzt werden. Auch "temporären Userswitch" könnte man dabei machen, indem man die Datei in /var/run geeignet verwaltet. Für all das benötigt man ein gutdurchdachtes suid login-Programm (das man ohnehin braucht) und eine gutdurchdachte Sammlung von udev-Regeln, die (in Abhängigkeit von der erwähnten Datei in /var/run) die Rechte neu eingesteckter Geräte setzen u.ä.

Die de-facto Aushebelung der bewährten Unix-Dateirechte durch permanent laufende Dämonen ist der vollkommen falsche Weg dazu: Unnötiger Resourcenverbrauch, unnötiges und eigentlich unkontrollierbares Sicherheitsrisiko, Programme und Benutzer können nicht mehr feststellen, was sie tatsächlich dürfen usw. - eine gigantische Fehlkonzeption.

Wäre nicht so schlimm, wenn man den Mist in die Tonne treten könnte, wo er hingehört. Leider aber will RedHat die Sache jedem aufnötigen. So benötigen beispielsweise k3b und kaudiocreator udisk (wozu eigentlich?), was wiederum policikit und consolekit benötigt. Für k3b gibt es als Ersatz xfburn, aber Letzteres hat bei mir schon unbrauchbare CDs produziert; für kaudiocreator kenne ich gar keinen Ersatz.

----------

## astaecker

@ ConsoleKit, PolicyKit

 *mv wrote:*   

> Beispiel consolekit und policykit: Für Desktopumgebungen ist es durchaus zweckmäßig, dass der eingeloggte Benutzer "registriert" wird und zusätzliche Rechte bekommt. Dazu gibt es aber vorgehesene Mechanismen: Registrieren sollte in einer Datei in /var/run (oder einen ähnlichen Pfad) passieren, nicht durch einen ständig laufenden Dämon, der permanent Resourcen frisst, und auch sonst nur Nachteile hat. Beim Einloggen können dann auch die Rechte der Laufwerke entsprechend auf den User gesetzt werden. Auch "temporären Userswitch" könnte man dabei machen, indem man die Datei in /var/run geeignet verwaltet. Für all das benötigt man ein gutdurchdachtes suid login-Programm (das man ohnehin braucht) und eine gutdurchdachte Sammlung von udev-Regeln, die (in Abhängigkeit von der erwähnten Datei in /var/run) die Rechte neu eingesteckter Geräte setzen u.ä.
> 
> Die de-facto Aushebelung der bewährten Unix-Dateirechte durch permanent laufende Dämonen ist der vollkommen falsche Weg dazu: Unnötiger Resourcenverbrauch, unnötiges und eigentlich unkontrollierbares Sicherheitsrisiko, Programme und Benutzer können nicht mehr feststellen, was sie tatsächlich dürfen usw. - eine gigantische Fehlkonzeption.
> 
> Wäre nicht so schlimm, wenn man den Mist in die Tonne treten könnte, wo er hingehört. Leider aber will RedHat die Sache jedem aufnötigen.

 

Der Resourcenverbrauch von PolicyKit und vor allem ConsoleKit sollte wohl wirklich nicht der Rede wert sein. Beides sind DBus Dienste, so dass sie passiv vor sich hin dümpeln, bis sie über DBus von einem Programm aktiviert und genutzt werden.

ConsoleKit und PolicyKit leisten das, was du beschreibst, und noch einiges mehr. PolicyKit aber bietet ein viel feingliedrigeres Rechtesystem als die bewährten Unix-Dateirechte, was auch der Grund für PolicyKit war. Siehe dazu http://de.gentoo-wiki.com/wiki/PolicyKit.

Gerade durch die Trennung in Komponenten mit sorgsam gewählten Schnittstellen lassen sich die einzelnen Komponenten besser warten und deren Sicherheitsrisiko besser überblicken. Eine All-in-One Software ist dagegen schwierig zu verwalten. Gute Beispiele dafür sind HAL und Kmail1.

 *mv wrote:*   

> So benötigen beispielsweise k3b und kaudiocreator udisk (wozu eigentlich?), was wiederum policikit und consolekit benötigt.

 

Um das Rad nicht neu zu erfinden. udisks informiert k3b darüber, ob sich ein Medium im Laufwerk befindet und um welchen Typ (CD, DVD, usw.) es sich handelt.

@ gconf, dconf

So wie es aussieht, beschweren sich hier alle nur, das sie vorhandene Einstellungen nicht finden. Das ist aber ein Problem der Programme oder deren Entwickler. Um hier auch mal einen Vorteil von gconf bzw. dconf zu nennen: das Einlesen einer binären Datenbank mit Einstellungen geht beim Systemstart schneller als das Parsen von Textdateien.

----------

## schmidicom

@astaecker

Ist ja schön und gut das man mit Hilfe von policykit so extrem ins Detail gehen kann aber seien wir doch mal ehrlich wie viele brauchen das? Ich nicht und wenn man sich im Internet umsieht offensichtlich viele andere auch nicht.

Die Momentane Situation ist so als würden die Kernelentwickler hergehen und verlangen das so was wie NSA SELinux im Kernel drin sein müsste weil sonst ohne kein boot mehr möglich wäre.   :Shocked: 

udisks und seine verwandten könnten meiner Meinung nach auch ohne policykit (und somit auch ohne consolekit) laufen nur eben nicht ganz so genau was die Berechtigungen anbelangt aber dennoch brauchbar und vor allem "benutzerfreundlich". Früher konnten die Desktopumgebungen die Kiste ja auch herunterfahren ohne das ein consolekit mit polickit erst darüber entscheiden musste ob dies erlaubt ist oder nicht. Auch fehlt es doch insbesondere bei Policykit an einem vernünftigen Editor für all die Aktionen die dort gespeichert sind, es kann doch nicht sein das z.B. KDE erst so einen schreiben muss.

Und bei dconf/gconf ist es doch genau so, warum wird einem dieses Ding an jeder zweiten Ecke regelrecht aufgezwungen wenn es auch anders geht? Wenn jemand lieber alles in Textfiles hat sollte das doch wirklich einem selbst überlassen werden und ausserdem glaube ich nicht das der Geschwindigkeitsvorteil so extrem ausfällt wenn alles binär gespeichert wird. Dazu kommt noch eine andere Sache, sollte mal der dconf/gconf Editor aus irgendeinem Grund nicht mehr benutzbar sein ist auch jede Möglichkeit dahin auf andere weise an die Daten ran zu kommen denn ich glaube nicht das ein "nano -w" dann noch funktioniert.

EDIT:

OK dconf/gconf speichern scheinbar nichts in binärform sondern in xml, Danke franzf.

Womit sich aber auch der angebliche Geschwindigkeitsvorteil in Luft auflöst.Last edited by schmidicom on Wed Jan 18, 2012 10:58 am; edited 1 time in total

----------

## franzf

 *astaecker wrote:*   

> Um hier auch mal einen Vorteil von gconf bzw. dconf zu nennen: das Einlesen einer binären Datenbank mit Einstellungen geht beim Systemstart schneller als das Parsen von Textdateien.

 

Nur dconf ist binary. gconf ist xml, und das dauert deutlich länger zu parsen als ne .ini.

Ich bin froh, wenn Programme ihre settings per .ini abspeichern, denn dann kann man auch mal per vim Hand anlegen, wenn der Start streikt.

Hatt ich schon ein paar mal (jetzt schon länger nicht mehr), dass plasma nicht hochkam, weil ein applet nen SegFault verursachte.

Option 1: komplette config löschen, Stück für Stück alten Desktop wieder herstellen

Option 2: .ini editieren, nur das fehlerhafte applet rausnehem.

Was ist schöner?

----------

## Knieper

 *astaecker wrote:*   

> Der Resourcenverbrauch von PolicyKit und vor allem ConsoleKit sollte wohl wirklich nicht der Rede wert sein.

 

Vlt. auf Deinem Desktop, es gibt aber noch andere Rechner.

 *Quote:*   

> Um hier auch mal einen Vorteil von gconf bzw. dconf zu nennen: das Einlesen einer binären Datenbank mit Einstellungen geht beim Systemstart schneller als das Parsen von Textdateien.

 

Das ist dann wieder eine messbare Größe im Ggs. zu dauerlaufenden Prozessen? Wenn das ein Vorteil sein soll, dann müssten

a) das Textformat oder die Konfiguration zu komplex und damit kaputt sein oder

b) alle Konfigurationsdaten wirklich gelesen und womöglich im Speicher gehalten werden und damit wären beide Ansätze kaputt.

Der Quatsch löst Probleme die es überhaupt nicht gibt. Globale Konfigurationen kann man in /etc oder als Default-Verhalten des Programms festlegen, lokales Verhalten in ~/ oder ~/.config. Der gconf-Müll hat dann so tolle Nebenwirkungen, dass Programme ohne nicht mehr vernünftig nutzbar sind, weil die entspr. Optionen nicht mehr als cli-Parameter angeboten werden.

----------

## musv

gconf und gvfs:

Wurde bei mir installiert, obwohl ich 'ne KDE-Umgebung hab. Grund ist vermutlich, weil ich Anjuta mit devhelp installiert hab. Und das zieht das ganze Gnome-Gerödel nach sich. Außer der Warnmeldung bei der Installation diverser Pakete, dass kein Mimi-Typ gefunden werden konnte, hatte ich noch keine Anwendungsmöglichkeit entdeckt.

policykit / consolekit / upower / udisks

musste ich zwangsläufig als Abhängigkeit für k3b installieren. Ein weiterer "Vorteil" war, dass dadurch meine Holde endlich auf den Cardreader ohne Root-Rechte zugreifen konnte. Kann man aber auch alles über udev-Regeln lösen. 

PS: Einfach nachvollziehbar ist diese Konfiguration nicht gerade. Für alle anderen außer der letzten Box seh ich irgendwie keinen so richtigen Sinn.

Zeroconf

Damit konnte ich mich noch nie anfreunden. Ich finde es jetzt auch nicht so schwierig, den jeweiligen Geräten Namen zuzuordnen, die im Heimnetzwerk in die /etc/hosts auf jedem Rechner einzutragen und die Rechnernamen dann zu verwenden. Das Zeroconf-Gedöns musste ich über package.provided von meinem Rechner fernhalten.

Pulseaudio

Mein persönliches Hassprojekt. Kann alles, was OSS4 kann und noch etwas mehr. Das Problem des exklusiven Device-Zugriffs wurde mit OSS4 schon mehr als brauchbar gelöst. Irgendeine umständliche asound.conf war dafür nicht notwendig. 

Das Schlimme für mich an Pulseaudio ist aber die virenartige Einpflanzung ins System. Nach der Anschaffung eines HTPC wollte ich Pulseaudio dazu verwenden, den Sound von einem Rechner auf den anderen on the fly übertragen zu können. Aber Pulseaudio meinte jetzt, dass es das Default-Device von KDE sein wollte und wurde gleich bei jedem Systemstart mit geladen, erzeugte dabei eine spürbar höhere CPU-Auslastung und Knattern im Sound. Deaktivieren in der Systemsteuerun ging nicht, da OSS scheinbar nur 'ne Fallback-Option ist. Erst die Deinstallation von Pulseaudio erledigte das Problem. 

Das ist für Pulseaudio aber noch nicht genug: Die Soundausgabe per OSS ist nicht mehr offiziell vorgesehen, da musste ich irgendwas im Ebuild ändern. Und die Installation des padevchooser zum Überträgen des Soundstreams auf andere Rechner/Devices zieht wieder Zeroconf als Abhängigkeit mit. 

Auf alle Fälle ist Pulseaudio wieder ein wunderbares Beispiel für die verkorkste Soundarchitektur unter Linux.

Da würde ich mir ein Soundsystem wünschen:

- ausgereifte Treiber 

- eine Core-Lib 

- alle restlichen Funktionalitäten (Netzwerk, VMix/DMix, verschiedene Resampler, ...) über Plugins

D.h. Zusammenlegung von OSS und Alsa, alle anderen Soundlibs und Soundserver als Erweiterungsplugins.

----------

## mrsteven

 *franzf wrote:*   

> Nur dconf ist binary. gconf ist xml, und das dauert deutlich länger zu parsen als ne .ini.

 

Bisher hatte gconf ja gegenüber dieser unsinnigen Registry in Windows immerhin den Vorteil, dass das Speicherformat notfalls von Hand les- und bearbeitbar war (einigermaßen wenigstens). Wenn ich das noch richtig in Erinnerung habe, dann soll ja dconf gconf irgendwann ablösen, nur hat das dann gar keinen Vorteil mehr gegenüber der Registry. Für Änderungen in einem vernünftigen Konfigurationssystem braucht man einen Editor und sonst nichts.

Wie hier schon geschrieben wurde, Einstellungen gehören als übersichtliche Textdateien nach /etc bzw. nach ~/ (besser noch: nach ~/.config). Eine wirklich einheitliche Namenskonvention, an die sich jede Anwendung hält, wäre allerdings wünschenswert.

Auch wenn's schon genannt wurde: Strigi und Nepomuk gehören für mich auch dazu. Das Zeug läuft nicht stabil, legt in den Standardeinstellungen bei mir eine Datenbank mit sagenhaften 6GB an und löst kein echtes Problem. Ich bin nicht die Ordnung in Person, trotzdem muss ich vielleicht alle paar Monate eine Datei suchen - und das ging bisher immer noch mit grep.

Mich wundert, dass systemd hier noch nicht genannt wurde.

Motif darf wegen optischer Körperverletzung von mir aus auch langsam mal aussterben, leider braucht DDD das.

----------

## mv

 *Quote:*   

> Der Resourcenverbrauch von PolicyKit und vor allem ConsoleKit sollte wohl wirklich nicht der Rede wert sein. Beides sind DBus Dienste, so dass sie passiv vor sich hin dümpeln, bis sie über DBus von einem Programm aktiviert und genutzt werden.

 

Es gibt prinzipiell keine Daemonen, die "vor sich hin dümpeln": Irgendeine Routine (und sei es der Kernel) muss regelmäßig checken, ob der Zeitpunkt zum Aufwachen da ist. Und beide fressen schon ziemlich viel Prozent der 128MB Speicher meiner kleineren Rechner - ob da ein Kompilationsvorgang 20% mehr swappen muss oder nicht, merkt man deutlich an der Zeit. Besonders ärgerlich ist das, weil bei einer vernünftigen Implementierung über udev-Regeln eben keine Ressourcen benötigt würden.

 *astaecker wrote:*   

> ConsoleKit und PolicyKit leisten das, was du beschreibst, und noch einiges mehr.

 

Ja, sie schaffen nämlich einen unnötigen zusätzlichen Komplexitätslayer und hintergehen damit das KISS-Prinzip, das fundamental für jede Sicherheit ist.

 *Quote:*   

> Eine All-in-One Software ist dagegen schwierig zu verwalten.

 

Eben deswegen ist es eine Riesendummheit, eine einfache Konfiguration (etwa mit udev-Regeln wie ich sie skizzierte) durch ein komplexes Programmkonstrukt zu ersetzen. Nur als Beispiel: Jeder Bug in dbus ist jetzt so gut wie ein root-exploit.

 *Quote:*   

>  *mv wrote:*   So benötigen beispielsweise k3b und kaudiocreator udisk (wozu eigentlich?), was wiederum policikit und consolekit benötigt. 
> 
> Um das Rad nicht neu zu erfinden. udisks informiert k3b darüber, ob sich ein Medium im Laufwerk befindet und um welchen Typ (CD, DVD, usw.) es sich handelt.

 

Ein vernünftiges Programm würde dann halt nicht erkennen, dass keine Disk eingelegt ist. k3b findet dann aber nicht einmal den Brenner selbst, der eigentlich nichts mit udisks zu tun haben sollte. Angeblich handelt es sich ja um eine modulare Lösung und nicht um eine all-in-one Software.

 *Quote:*   

> @ gconf, dconf
> 
> So wie es aussieht, beschweren sich hier alle nur, das sie vorhandene Einstellungen nicht finden.

 

Nein, das Problem ist, dass Einstellungen, die an anderer Stelle erfolgen müssen und sollten (etwa Schriften), hier redundant gespeichert werden und damit für Unordnung und potentielle Probleme sorgen: Dies ist genau der Grund, weshalb z.B. yast von SuSE so umstritten war.

 *Quote:*   

> Um hier auch mal einen Vorteil von gconf bzw. dconf zu nennen: das Einlesen einer binären Datenbank mit Einstellungen geht beim Systemstart schneller als das Parsen von Textdateien.

 

Um mal den Vorteil ohne gconf bzw. dconf zu sehen: Wenn ich beim Systemstart gar nichts einlesen muss, weil nämlich die Einstellungen der fonts u.ä. bereits vom letzten Systemstart richtig sind, geht es noch viel schneller.   :Wink: 

----------

## mv

 *mrsteven wrote:*   

> Mich wundert, dass systemd hier noch nicht genannt wurde.

 

Ich hatte ihn in der Auflistung von Poetterings Fehlkonzeptionen genannt. Eine typische Schnappsidee: Um beim Systemstart 1-2 Sekunden zu sparen, einen Daemonen laufen zu lassen, der permanent Ressourcen frisst.   :Rolling Eyes: 

----------

## avx

Leicht OT, aber was mich seit Jahren stört:

a) der "Wahn", irgendwelche non-standard Libraries zu verlangen, obwohl davon nur ein minimales Subset genutzt wird. Anstatt mal 5-10 Zeilen Code selber zu schreiben, der genau macht was man braucht, lieber einen Rattenschwanz an komischem Zeug ins System ziehen.

b) der ganze NIH-Mist. Wieviele z.B. GTK-Clones gibt's von amaroK? Warum kann man da nicht einfach ein paar gute und universelle Backends schreiben, an denen man gemeinsam arbeitet und dann halt nur ein paar verschiedene GUIs/CLIs bereitstellen? Klappt z.B. wunderbar mit mpd oder mplayer. Derzeit ist es verdammt nervig, seine Daten umzuziehen, wenn man - aus welchen Gründen auch immer - die Programme wechseln will/muss.

c) Gentoo-spezifisch, wenn ebuild-Maintainer zu faul sind, wirklich alle optionalen Deps rauszufinden und einfach mal alles im ebuild forcieren, was sie für sinnvoll halten. KA wieviele z.B. Dokumentationssysteme (doxygen, asciidoc, ...) ich allein auf dem System habe, obwohl sie vollkommen unnötig sind.

Im Namen der "Nutzerfreundlichkeit" wird seit Jahren Linux alles entzogen, was es ursprünglich mal ausgemacht hat - sehr technisch, aber auch für Laien relativ leicht nachvollzieh- und fixbar.

----------

## Necoro

 *mv wrote:*   

> Ich hatte in Erinnerung, dass gnome ein System hatte, bei dem Programme schnell binär statt über den xml-Umweg miteinander kommunizierten. Aber ich kann falsch liegen.

 

Meinst du das komische Orbit/Bonobo-Zeugs? Das war glaube ich vorrangig komplett unverständlich ^^.

Aber noch kurz zu DBus: Wenn ich das richtig sehe, werden die Daten binär kommuniziert. XML wird nur für die Konfiguration verwendet. Ansonsten ist DBus selber glaube ich nicht so das Problem, denn ich verstehe das Problem was man lösen will: Programme/Programmteile sollen miteinander kommunizieren können ohne dass jedes sein eigenes IPC-Modell implementiert. Problematisch ist mal wieder vorrangig der Einsatz (warum müssen sich Systemteile darüber unterhalten? das sind doch in der Regel so wenige, dass man deren Kommunikation auch anders fest verdrahten kann).

----------

## ScytheMan

interessant das bis jetzt noch keiner ati-drivers genannt hat.   :Very Happy: 

nich nur das es n blob is sondern z.b. auch das xv mit x-server 1.11 nicht mehr funktioniert und alle videos den xserver crashen lassen.

bleibt nur ein downgrade des xservers und die hoffnung dass sie es endlich diesen monat gefixt haben.

----------

## musv

 *ScytheMan wrote:*   

> interessant das bis jetzt noch keiner ati-drivers genannt hat.  

 

??? Gibt's tatsächlich noch Leute, die sich einen Rechner mit ATI-Karte kaufen?

Meine letzten 3 gekauften Rechner haben alle 'ne Nvidia-Karte drin. Konnte mich bisher nicht beschweren.

----------

## Knieper

 *musv wrote:*   

> Gibt's tatsächlich noch Leute, die sich einen Rechner mit ATI-Karte kaufen?

 

In den letzten zwei Jahren las man immer das Gegenteil. Momentan gilt doch: die Treiber für ATI, Intel und Nvidia sind scheiße. Ich wüsste zur Zeit nicht, was ich mir für eine Karte kaufen würde. Allerdings bin ich schon die letzten 10 Jahre gut ohne die drei Genannten ausgekommen.

----------

## avx

Naja, bei ATI/AMD sind die Treiber halt aus Tradition Mist, das war schon unter Windows so und so ist's auch unter Linux geblieben.

----------

## schmidicom

Nur mal so am Rande hat eigentlich schon mal jemand versucht (nur als Beispiel) den Programmierern von udisk und upower den Vorschlag zu unterbringen die Software so zu schreiben das sie wahlweise mit oder ohne Policykit als Rechtesystem compiliert werden kann?

----------

## mv

 *schmidicom wrote:*   

> den Programmierern von udisk und upower

 

Das sind m.W. alles hauptamtliche Angestelle von Redhat und damit vermutlich sehr enge Arbeitskollegen von Poettering, dessen erklärtes Ziel es ist, sein "geniales" Daemonen-Konzept jedem Anwender als "Standard" aufzuzwingen. Viel Spaß beim Intrigieren!   :Wink: 

----------

## cryptosteve

Mich stören weniger Programme und Tools an sich, sondern eher der sich fortlaufend ändernde vermeintliche Standard unter Linux. Mag ja sein, dass nicht alles immer perfekt ist, aber speziell Sachen wie hal, udev & co scheinen schneller deprecated zu sein, als man mit dem Umkonfigurieren hinterher kommt. Unter Linux ist das gerade noch zu verschmerzen, aber der Rest der OpenSource-Welt (wie z.B. die BSDs) haben kaum Chance, dem noch zu folgen, zumal sich selbst simple Sachen wie Desktop-Environments immer mehr 'linuxifizieren'.

----------

## LinuxTom

 *Knieper wrote:*   

> Allerdings bin ich schon die letzten 10 Jahre gut ohne die drei Genannten ausgekommen.

 

Und welche hast Du?

----------

## Knieper

Eine vom renommierten Hersteller aus Kanada. Beim Rechnerneukauf würde es wohl eine integrierte von Intel werden, obwohl ich normalerweise AMD-Rechner bevorzuge.

----------

## musv

 *mv wrote:*   

> Das sind m.W. alles hauptamtliche Angestelle von Redhat und damit vermutlich sehr enge Arbeitskollegen von Poettering

 

Waaaaah, Der ist tatsächlich für die ganzen Ärgernisse verantwortlich. Wieso hat der soviel Einfluss?

----------

## AmonAmarth

 *musv wrote:*   

>  *mv wrote:*   Das sind m.W. alles hauptamtliche Angestelle von Redhat und damit vermutlich sehr enge Arbeitskollegen von Poettering 
> 
> Waaaaah, Der ist tatsächlich für die ganzen Ärgernisse verantwortlich. Wieso hat der soviel Einfluss?

 

Weil er wohl gerne und gut die Klappe aufreisst und rhetorisch andere unterbuttert, die was gegen sein Zeugs sagen wollen. Siehe: http://www.youtube.com/watch?v=ZTdUmlGxVo0

Das fanden viele wohl letztes jahr unglaublich cool und lustig diese Aktion, ich empfand das eher als unverschämt die ganze Zeit dazwischen zu funken, da der Redner wirklich einen wichtigen Punkt zu sagen hatte.

----------

## schmidicom

 *AmonAmarth wrote:*   

>  *musv wrote:*    *mv wrote:*   Das sind m.W. alles hauptamtliche Angestelle von Redhat und damit vermutlich sehr enge Arbeitskollegen von Poettering 
> 
> Waaaaah, Der ist tatsächlich für die ganzen Ärgernisse verantwortlich. Wieso hat der soviel Einfluss? 
> 
> Weil er wohl gerne und gut die Klappe aufreisst und rhetorisch andere unterbuttert, die was gegen sein Zeugs sagen wollen. Siehe: http://www.youtube.com/watch?v=ZTdUmlGxVo0
> ...

 

Hmm ich bin verwirrt, wer machte den Vortrag gleich noch Herr Draxinger oder doch Poettering?

Eigentlich gebietet es ja die Höflichkeit das man so was nicht unterbricht und erst zum Schluss oder wenn man gezielt gefragt wird seinen Kommentar abgibt.

Also ich hätte nicht so viel Geduld mit dem Typen gehabt was vermutlich auch der Grund ist warum ich bei uns in der Firma keine Schulungen mehr mache.  :Wink: 

----------

## Max Steel

Zum Thema udisks "ganz aktuell":

Wer udisks installieren möchte braucht dashier in udev:

( ) gudev                                (   ) Local flag: enable libudev gobject interface (sys-fs/udev)

Und udisks wird vornehmlich von KDE verwendet (allein das Geräte-Plasmoid basiert darauf (glaube ich)

----------

## astaecker

 *Max Steel wrote:*   

> Zum Thema udisks "ganz aktuell":
> 
> Wer udisks installieren möchte braucht dashier in udev:
> 
> ( ) gudev                                (   ) Local flag: enable libudev gobject interface (sys-fs/udev)
> ...

 

Wo liegt das Problem? Das KDE die glib (implementiert gobject) verwendet? Man hätte dafür wohl auch ein C++-Binding verwenden können, aber da solche Middleware meistens zuerst für Gnome geschrieben wird, gibt es halt nur ein glib-Binding. Die Qt- und KDE-Entwickler können damit wohl leben. Und da glib als eine STL für C recht schlank und mittlerweile hochoptimiert ist, verbraucht es wohl auch nicht mehr Resourcen als jede andere Lösung.

Udisks wird mittlerweile in einiger Software verwendet, siehe DEPEND, PDEPEND und RDEPEND.

----------

## astaecker

 *musv wrote:*   

> Waaaaah, Der ist tatsächlich für die ganzen Ärgernisse verantwortlich. Wieso hat der soviel Einfluss?

 

Weil er Code schreibt. In den Bereichen hat sich lange nichts getan bzw. nicht das richtige, so dass er mit seiner Software offene Türen einrennt.

 *AmonAmarth wrote:*   

> Weil er wohl gerne und gut die Klappe aufreisst und rhetorisch andere unterbuttert, die was gegen sein Zeugs sagen wollen. Siehe: http://www.youtube.com/watch?v=ZTdUmlGxVo0
> 
> Das fanden viele wohl letztes jahr unglaublich cool und lustig diese Aktion, ich empfand das eher als unverschämt die ganze Zeit dazwischen zu funken, da der Redner wirklich einen wichtigen Punkt zu sagen hatte.

 

Sicher war der Redner mit der Kritik überfordert und daher bedauernswert, andererseits wäre es wohl auch nicht richtig und sinnreich gewesen, das Publikum 50 Minuten lang mit falschen Fakten zu füttern. Auch wenn das Thema Leute anspricht und die Aussage für einige Anwendungsfälle richtig ist, so ist der Vortrag schlecht recherchiert und in seinem Anwendungsgebiet beschränkt. All die genannte Software ist notwendig, weil deren Funktionen von einem modernen Desktop erwartet wird. Und den hat Lennart im Blick.

Der Vortrag ist bewusst provokant gemacht und der Redner nach einigen korrekten Einwürfen aus Trotz uneinsichtig, so dass der Redner gegen Lennart, der u.a. seine Software verteidigt, den kürzeren zieht.

----------

## pablo_supertux

 *mv wrote:*   

> 
> 
> Beispiel consolekit und policykit: Für Desktopumgebungen ist es durchaus zweckmäßig, dass der eingeloggte Benutzer "registriert" wird und zusätzliche Rechte bekommt. Dazu gibt es aber vorgehesene Mechanismen: Registrieren sollte in einer Datei in /var/run (oder einen ähnlichen Pfad) passieren, nicht durch einen ständig laufenden Dämon, der permanent Resourcen frisst, und auch sonst nur Nachteile hat.

 

Aha, das ist also der Grund, warum ich in meinem Arbeitsnotebook (mit Debian 6) mplayer nicht verwenden kann, wenn ich per SSH eingeloggt bin und gleichzeitig kein X läuft.

----------

## Yamakuzure

 *avx wrote:*   

> c) Gentoo-spezifisch, wenn ebuild-Maintainer zu faul sind, wirklich alle optionalen Deps rauszufinden und einfach mal alles im ebuild forcieren, was sie für sinnvoll halten. KA wieviele z.B. Dokumentationssysteme (doxygen, asciidoc, ...) ich allein auf dem System habe, obwohl sie vollkommen unnötig sind.

 Ja. Zum Beispiel habe ich gconf auf meinem KDE-Rechner, weil ich für Code::Blocks wxGTK benötige, und das benötigt gconf wenn gstreamer verwendet wird. Nur das gstreamer mitlerweile Pflicht ist, da KDE sich von Xine verabschiedet hat. Aber _wofür_ brauchts dann gconf? (Wofür braucht wxGTK bei mir gstreamer? Ich glaub ich schmeiß das raus aus den USE-Flags...)

Aber wie auch immer, ich bin nicht so unbedingt heiß drauf jedes nötige Byte zu sparen, da moderne Hardware genug Resourcen hat. Mein Akku hält 5-6 Stunden, ich brauche aber nie mehr als 1-2. Man kann auch auf hohem Niveau jammern.

Das Einzige, was ich wirklich wirklich dringend in /etc/portage/package.mask benötige sind diese Zeilen:

```
# Alles an GTK3 hat hier Hausverbot:

>=gnome-base/gvfs-1.10.1

>=sys-apps/gnome-disk-utility-3.0.0

x11-libs/gtk+:3

x11-libs/vte:2.90
```

Mehr brauche ich (zum Glück) nicht um GTK3 fern zu halten.

Aber schauen wir mal nach den Hauptakteuren des allgemeinen Aufregens:gconf

Ich weiß nicht warum es da ist, warum es benötigt wird, und wofür das gut sein soll. Na gut, eigentlich ist es mal einen Versuch wert, es runterzuwerfen, vielleicht gelingt mir das ja?gvfs

Das ist eine harte Abhängigkeit von libgnome. Das befindet sich wegen libgnomeui auf meinem Rechner, welches von libgnome-python (hart) benötigt wird. Letzteres kam dank egg-python auf mein system, was zwingend von phctool verwendet wird, was ich mal installiert habe um phc-intel zu testen.

Oh! Ich kanns runterschmeißen. Yippieh! (testen ist ja lange beendet!)*kit und u*

Finde ich nicht schlimm. Macht alles, zumindest aus Sicht eines KDE4-Anwenders, recht einfach. Ich kann aber jeden Nicht-KDE-Nutzer verstehen, der sich von den (nicht gerade wenigen) Programmen angenervt ist.SystemD

Die Grundidee finde ich garnicht so schlecht. Ich habe mal spaßeshalber eine VM mit Arch und systemd aufgesetzt (geht ja schnell), und der Boot-Prozess ist ... nunja ... wow. Für die übrigen "Vorteile", die systemd bringen soll, ist glaube ich noch abzuwarten, wie sich der ganze Rotz entwickelt.PulseAudio

Ja. Ein g-e-n-i-a-l-e-s System wenn man einen Headless Media-Server für seine Wohnung bauen will. Für ein Laptop ist das ungefähr so, als ob man sein Fahrrad stehen lässt, und die 50 Meter zum Bäcker im Leopard 2 zurücklegt... (Dafür bekommt man die Schrippen zwei cent günstiger.  :Wink: )Poettering

Der hat schon was drauf. Auch wenn so einige komische Ideen dabei sind, finde ich es nicht richtig seine Arbeit als Ganzes daran zu bewerten, dass er ein ziemlich unsympathischer Fatzke ist.

----------

## Knieper

 *Yamakuzure wrote:*   

> Poettering
> 
> Der hat schon was drauf. Auch wenn so einige komische Ideen dabei sind, finde ich es nicht richtig seine Arbeit als Ganzes daran zu bewerten, dass er ein ziemlich unsympathischer Fatzke ist.

 

Ich habe kein Problem damit, dass er ein überheblicher Fatzke ist. Ich habe ein Problem damit, dass er Standards vorgeben will die keine Alternativen vorsehen. Systemd soll zukünftig auch Session von DEs verwalten und in allen gängigen Distributionen eingesetzt werden. Die Probleme die er dabei beheben will sind hausgemacht. Wieso booten denn viele Rechner so lahm? Weil sie die ganzen überflüssigen Dämonen der Bloatdesktops starten. Was soll an meinem Rechner schneller parallel laufen, wenn er nur einen Kern hat? Der braucht keine 20s zum Start und belegt danach ~30MB RAM. Mein Router hat auch nur einen Kern und wenn ich ein RaspberryPi in die Finger bekomme, wird die auch nicht mehr Kerne haben. Von seiner ganzen Software habe ich nichts auf dem Rechner, nicht mal dbus weil freedesktop.org und Poettering bei mir inzwischen Vixie-Status   :Wink:   erreicht haben.

----------

## avx

 *Quote:*   

> Aber wie auch immer, ich bin nicht so unbedingt heiß drauf jedes nötige Byte zu sparen, da moderne Hardware genug Resourcen hat.

 Definiere modern? Mein embedded System und mein (hoffentlich zukünftiger) R-Pi laufen von ner MicroSD, da will ich nicht extra mehr Geld ausgeben müssen, nur um unnötiges Zeug drauf zu haben.

Mich frustriert's halt, dass Gentoo ein Baukasten-System ist, in manchen Fällen aber doch nur Playmobil und nicht Lego, weil manche eben doch zu faul sind. Ich kann diese Faulheit ja nachvollziehen, frag mich dann aber, ob man die betroffenen Pakete nicht an engagiertere Leute abgeben sollte.

Zum Thema Poettering, mich nervt, dass alles so um Linux gebaut wird und das nicht optional. Für manche Sachen bevorzug ich dann doch BSD und über kurz oder lang hat das drunter zu leiden.

Auch dieser ganze Mist mit dutzenden, dauernd wechselnden Backends nervt. Erst xine, dann mplayer, dann gstreamer, dann wieder dies und dann morgen ganz was neues. Mir geht's auf die Nüsse, ich bin mplayer-Fan und der spielt bei mir alles ab, dennoch bekomm ich von allen Seiten gstreamer aufgezwängt, der will aber manchmal nicht alles spielen. Opera z.B. konnte eine zeitlang alles via HTML5 spielen, was gstreamer lokal supported hat(z.B. dann doch auch h.264), irgendwann hat Opera, da war man als Linuxer in der komfortablen Position, alles haben zu können und dann kommt Opera daher und beschränkt das wieder künstlich auf Ogg/Theora. Warum dieser Dreck, warum kann HTML5 nicht einfach nen normalen Link raushauen und jeder spielt's mit seinem bevorzugten Backend ab?

Derzeit nervt mich auch nzbget, super Programm für meine Zwecke, aber ich mag die Farbgestaltung nicht bzw. sie passt nicht in mein restliches "Design", anstatt dass da aber wie üblich ne Config da ist oder man via Xressources spielen kann, nein, muss ich wieder den Source von Hand patchen.

Von webkit sollte es mal einen reinen xlib-Port geben, ist nichts draus geworden, jetzt hab ich nur dafür GTK auf der Platte.

Dann gibt's derzeit keinen simplen Loginmanager, auf dem man, ala xdm, Sachen laufen lassen kann(conky z.B.), der es aber auch gleichzeitig erlaubt, einen Default-User zu definieren. GDM/KDM wollen, zumindest laut portage, einen enormen Rattenschwanz, lightdm will auch wieder gtk oder qt, etc.

----------

## musv

 *Yamakuzure wrote:*   

> PulseAudio
> 
> Ja. Ein g-e-n-i-a-l-e-s System wenn man einen Headless Media-Server für seine Wohnung bauen will. Für ein Laptop ist das ungefähr so, als ob man sein Fahrrad stehen lässt, und die 50 Meter zum Bäcker im Leopard 2 zurücklegt... (Dafür bekommt man die Schrippen zwei cent günstiger. )
> 
> Poettering
> ...

 

Ich hab mir mal den obigen Vortrag von Draxinger und Poettering Teilen reingezogen. Also erstmal war der Draxinger extrem oberflächlich. Er strauchelte leider schon bei den ersten Details, während der Poettering mit Detailwissen glänzte. Auch die sprachlichen Niveaus waren durchaus in verschiedenen Welten. Gut Poettering wurde in Guatemala geboren, ist in Rio und Hamburg aufgewachsen. Wenn man Spanisch, Portugiesisch und Deutsch als Muttersprachen hat, wird zu Englisch nicht mehr viel fehlen.

Der ganze Vortrag war auch als ein reiner Angriff auf Poetterings Arbeit zu sehen. Klar, dass der sich sowohl rechtfertigen als auch die ganzen Oberflächlichkeiten und Halbwahrheiten aus der Welt schaffen wollte. Zum Schluss kam Poettering mit dem Argument: "Hey, es ist alles frei. Wenn's euch nicht gefällt, müsst ihr es nicht verwenden. Schreibt 'nen Patch, der die Unterstützung aus den Paketen wieder rausnimmt." Im Grunde genommen hat er damit recht. Aber zum ersten Mal fand ich diesen Satz zum Kotzen, weil es eben für Außenstehende nicht so einfach ist, einfach mal einen Patch zu schreiben. 

Avahi

Ich erinnere mich noch an den Spagat, wie ich jahrelang das mDNS/Avahi-Zeux von meinem Rechner ferngehalten hab (etc/portage/package.provided). Ich empfinde das Projekt durchaus als sinnvoll, in meinem Heimnetzbereich hab ich aber keine Anwendung dafür und will es da auch nicht haben. 

*kit

Soweit ich mich erinnere (Achtung Halbwissen) braucht udisks auch polkit. Damit hätten wir auch wieder die Abhängigkeit zu Consolekit und auch pam. Leider ist K3B nicht mehr in der Lage, die CD-Laufwerke ohne *kit zu finden. Also musste ich mich geschlagen geben und das Zeug installieren. Den Brenner benutz ich evtl. 1x pro Jahr. Von daher kann man sich schon streiten, ob der permanent laufende Daemon jetzt wirklich notwendig ist. D.h. aufgrund K3b hab ich jetzt zusätzlich: udisks, devicekit, polkit, consolekit, pam. 

Faulheitsmäßig anzumerken ist, dass ich dadurch den Usern die Möglichkeit zum Mounten von USB-Datenträgen geb. Da hätte ich mich sonst durchaus erstmal intensiver wieder mit UDEV-Regeln beschäftigen müssen, um z.B. auch das Mounten mit Partitionsnummern hinzubekommen. 

Momentan ärger ich mich gerade auf meinem HTPC wieder extrem mit Consolekit rum, da scheinbar die Kombination:

inittab / mingetty AutoLogin -> .bashrc mit startx -> .xinitrc mit xbmc standalone 

mir keine aktive Session in Consolekit liefert. D.h. der Sinn von Consolekit/Polkit, dass ich meinen Rechner mit Knopfdruck auf der Fernbedienung runterfahren kann, ist wieder weg. Über den Umweg der Vorschaltung von slim bekomm ich die Session. Nur ist diese Lösung unakzeptabel. 

Ob das Mounten von USB-Datenträgern in XBMC jetzt generell oder nur mit *kit geht, weiß ich noch nicht. Muss ich noch intensiver testen. 

Pulseaudio

Hab ich oben schon mal erwähnt. Dumm ist halt auch hier der Einfluss. Skype geht ohne Alsa oder Pulseaudio gar nicht mehr, VMWare ebenso. KDE läuft prima mit OSS. Hat man Pulseaudio installiert, wird das allerdings automatisch von KDE gestartet. Und KDE jagt dann auf Teufel komm raus alles über Pulse. Nur brauch ich halt auf einem lokalen Rechner mit einer Soundkarte keinen zwischengeschalteten Soundserver. Ob XBMC "bit perfect" übertragen kann, weiß ich nicht. Google meldet da Widersprüchliches. Ich brauchs auch nicht zwangsweise auf meinem HTPC. Per NFS und MPD kann ich die Funktionalitäten von Ausgabe und Übertragung auch ohne Pulseaudio realisieren.

Btw. der Padevchooser, mit dem man die Soundsignale per GUI auf andere Devices umleiten kann, braucht wieder zwingend das mDNS/Avahi-Gedöns.

Fazit

Ich hab richtig Respekt vor Poettering. Er bewegt etwas, schafft etwas und löst auch einige generelle Probleme in der Linuxwelt. Nur bereiten mir seine Lösungen oft mehr Probleme als Nutzen. Und besonders gearscht ist man, wenn man auf seine Lösungen verzichten will. Denn die sind meist untereinander ziemlich voneinander abhängig und sind auch meist als notwendige Abhängigkeit in den großen Libs mit integriert. Braucht irgendein Paket ein Poettering-Projekt, hat man schnell gleich alle auf dem Rechner und damit 20 Daemons mehr am Laufen.

----------

## franzf

 *musv wrote:*   

> Der ganze Vortrag war auch als ein reiner Angriff auf Poetterings Arbeit zu sehen. Klar, dass der sich sowohl rechtfertigen als auch die ganzen Oberflächlichkeiten und Halbwahrheiten aus der Welt schaffen wollte.

 

Aber selber mit Halbwahrheit glänzen:

Gleich zu Beginn behauptet er allen Ernstes, phonon wäre nicht mehr aktuell, wurde mittlerweile durch QtMultimedia ersetzt. Qt hat QtMultimedia eingeführt, um ein umfangreicheres Multimedia-Framework mit Qt mitzuliefern, trotzdem gibt es für die einfachen Fälle weiterhin Phonon, und ich konnte nirgendwo finden, dass phonon (auf Qt-Seite) irgendwann wegfällt. phonon an sich ist weiterhin eine wichtige Basis für kde und wird natürlich aktiv weiter entwickelt.

Ich hab irgendwann nicht mehr weiter geschaut, weil es nervig war. Ich kann Draxingers Position nachempfinden. Ich find es nervig, so viel aufs Auge gedrückt zu bekommen, was dann aber nicht immer so funktioniert (fängt z.B. schon bei dbus an... zickt immer wieder).

Was ich an Poettering problematisch finde, ist die Macht, die er als Schaffer diese Quasi-Standards besitzt. Der Linux-Desktop liegt in seiner Hand. Ein Vorteil von freier Software war eigentlich immer der, dass sich verschiedene Gruppen verschiedene Sachen ausgedacht und umgesetzt haben. Wenns nützlich war, wurde es von vielen eingesetzt.

Dass innerhalb so kurzer Zeit immer neues hinzukam, sachen verworfen wurden (hal) oder umgeschrieben (PolicyKit->polkit), zeigt, dass die Entwicklung wirklich problematisch ist. Er ist nicht der einzige, der Programmieren kann, auch nicht der einzige, der Ideen hat (ob sie gut sind weiß ich nicht).

----------

## pablo_supertux

 *musv wrote:*   

> 
> 
> *kit
> 
> Soweit ich mich erinnere (Achtung Halbwissen) braucht udisks auch polkit. Damit hätten wir auch wieder die Abhängigkeit zu Consolekit und auch pam. Leider ist K3B nicht mehr in der Lage, die CD-Laufwerke ohne *kit zu finden. Also musste ich mich geschlagen geben und das Zeug installieren. Den Brenner benutz ich evtl. 1x pro Jahr. Von daher kann man sich schon streiten, ob der permanent laufende Daemon jetzt wirklich notwendig ist. D.h. aufgrund K3b hab ich jetzt zusätzlich: udisks, devicekit, polkit, consolekit, pam. 
> ...

 

Schon einige Leute beschweren sich hier wegen k3b. Ich hab k3b seit Jahren nicht mehr installiert und mir eigene bash skripte gebastelt: siehe http://sakuranohana.org/linux/tips.html#ISO

Das einzige, was ich nie herausgefunden habe, ist wie man Audio-CDs erstellt. Aber wer braucht denn heute noch Audio-CDs?

----------

## avx

 *pablo_supertux wrote:*   

> 
> 
> Das einzige, was ich nie herausgefunden habe, ist wie man Audio-CDs erstellt. Aber wer braucht denn heute noch Audio-CDs?

 

```
cdrecord -v -pad speed=1 dev=x,x,x -dao -audio -swab *.wav
```

?

Jedenfalls ging das früher so, ka ob sich da in der Zwischenzeit groß was dran geändert hat. Die *.wav werden in der Reihenfolge gebrannt, wie sie die Shell zuweist, ev. also händisch 01.,02.,... nennen.

----------

## astaecker

 *franzf wrote:*   

> Aber selber mit Halbwahrheit glänzen:
> 
> Gleich zu Beginn behauptet er allen Ernstes, phonon wäre nicht mehr aktuell, wurde mittlerweile durch QtMultimedia ersetzt. Qt hat QtMultimedia eingeführt, um ein umfangreicheres Multimedia-Framework mit Qt mitzuliefern, trotzdem gibt es für die einfachen Fälle weiterhin Phonon, und ich konnte nirgendwo finden, dass phonon (auf Qt-Seite) irgendwann wegfällt. phonon an sich ist weiterhin eine wichtige Basis für kde und wird natürlich aktiv weiter entwickelt.

 

Genau so war es auch (wohlgemerkt Ende 201), zumindestens von seitens Qt. Phonon wurde von KDE entwickelt, dann von Qt in Qt aufgenommen und später von Qt zugunsten von QtMultimedia fallengelassen. KDE ist nicht auf den QtMultimedia-Zug aufgesprungen und hat Phonon bis heute weiterentwickelt.

 *franzf wrote:*   

> Was ich an Poettering problematisch finde, ist die Macht, die er als Schaffer diese Quasi-Standards besitzt. Der Linux-Desktop liegt in seiner Hand. Ein Vorteil von freier Software war eigentlich immer der, dass sich verschiedene Gruppen verschiedene Sachen ausgedacht und umgesetzt haben. Wenns nützlich war, wurde es von vielen eingesetzt.
> 
> Dass innerhalb so kurzer Zeit immer neues hinzukam, sachen verworfen wurden (hal) oder umgeschrieben (PolicyKit->polkit), zeigt, dass die Entwicklung wirklich problematisch ist. Er ist nicht der einzige, der Programmieren kann, auch nicht der einzige, der Ideen hat (ob sie gut sind weiß ich nicht).

 

Erstmal hat Poettering nichts mit udev, consolekit, policykit, upower, udisks oder HAL zu tun. Und dann gibt es zu seiner Software Alternativen: OSS4 anstatt PulseAudio, upstart anstatt systemd. Die haben aber auch ihre Probleme, so dass sich die Entwickler aus guten Gründen für PulseAudio und systemd entschieden haben.

----------

## schmidicom

 *pablo_supertux wrote:*   

>  *musv wrote:*   
> 
> *kit
> 
> Soweit ich mich erinnere (Achtung Halbwissen) braucht udisks auch polkit. Damit hätten wir auch wieder die Abhängigkeit zu Consolekit und auch pam. Leider ist K3B nicht mehr in der Lage, die CD-Laufwerke ohne *kit zu finden. Also musste ich mich geschlagen geben und das Zeug installieren. Den Brenner benutz ich evtl. 1x pro Jahr. Von daher kann man sich schon streiten, ob der permanent laufende Daemon jetzt wirklich notwendig ist. D.h. aufgrund K3b hab ich jetzt zusätzlich: udisks, devicekit, polkit, consolekit, pam. 
> ...

 

Man kann auch app-cdr/nero benutzen wenn es mal was kommerzielles sein darf. Ich benutze das Ding nun schon sehr lange und bis jetzt hat es mich nie im Stich gelassen und immer funktioniert.

----------

## musv

 *astaecker wrote:*   

> Erstmal hat Poettering nichts mit udev, consolekit, policykit, upower, udisks oder HAL zu tun. Und dann gibt es zu seiner Software Alternativen: OSS4 anstatt PulseAudio, upstart anstatt systemd. Die haben aber auch ihre Probleme, so dass sich die Entwickler aus guten Gründen für PulseAudio und systemd entschieden haben.

 

Poettering und *kit:

```

27
```

http://www.freedesktop.org/wiki/Software/ConsoleKit

Mag sein, dass er nicht der Autor war. Mittlerweile scheint er jedoch bereits am nächsten Schritt zu arbeiten. Consolekit wird nicht mehr aktiv weiterentwickelt sondern soll in Systemd (wie war das mit upstart als Alternative?) integriert werden. Wie oben schon mal erwähnt, hat man dann keine Alternativen mehr - entweder man nimmt das Gesamtpaket oder man fängt an, Unmengen an Software zu patchen.

Dass man keine Alternativen hat, sieht man an diesem Beispiel (XBMC) gerade wieder schön. Das Runterfahren des Rechners per Fernbedienung veranlasst XBMC:

```
void CPowerManager::Initialize()

{

#if defined(__APPLE__)

  m_instance = new CCocoaPowerSyscall();

#elif defined(_LINUX) && defined(HAS_DBUS)

  if (CConsoleUPowerSyscall::HasDeviceConsoleKit())

    m_instance = new CConsoleUPowerSyscall();

  else if (CConsoleDeviceKitPowerSyscall::HasDeviceConsoleKit())

    m_instance = new CConsoleDeviceKitPowerSyscall();

#ifdef HAS_HAL

  else

    m_instance = new CHALPowerSyscall();

#endif

#elif defined(_WIN32)

  m_instance = new CWin32PowerSyscall();

#endif
```

D.h. man hat zur Auswahl:

DBUS + Consolekit + UPower

DBUS + Consolekit + DeviceKit.Power

HAL

D.h. die Alternative zu *kit ist HAL. Toll das. Sowohl bei Sudo als auch bei Polkit benötigt man für die Rechtevergabe Eingriffe in die Config außerhalb von XBMC. Sudo wären 2 Zeilen gewesen (halt + shutdown), Polkit ist da schon komplexer. Tja, die Entwickler von XBMC haben sich für das *kit-Geraffel entschieden.

Alternativen zur Pulseaudio:

Skype gab als letzte OSS-Version die 2.0.0.72 raus. Seitdem gab's nur noch Versionen, bei denen man die Auswahl zwischen Pulseaudio oder Alsa hat

Mozilla-Stuff: Mozilla setzt für die Soundunterstützung in HTML5 libsydneyaudio. Die unterstützt problemlos OSS. Leider sieht die Mozilla-Foundation das etwas anders, unterstützt für BSD OSS, verlangt aber unter Linux explizit Alsa. Firefox und Xulrunner konnte ich noch patchen, d.h. Firefox läuft problemlos mit OSS und HTML5. Bei Seamonkey scheiter ich momentan daran, den Alsa-Check aus dem Configure-Script rauszuschmeißen. Dafür reicht meine Ahnung bezüglich der Autotools nicht aus. Jedenfalls planen die Mozilla-Leute schon seit längerem die Umstellung von libsydneyaudio auf Pulseaudio.

----------

## Knieper

 *pablo_supertux wrote:*   

> Ich hab k3b seit Jahren nicht mehr installiert und mir eigene bash skripte gebastelt: siehe http://sakuranohana.org/linux/tips.html#ISO

 

Bashburn und cdw sind in Portage...

----------

## Yamakuzure

Also erstmal: Man kann, wie erwähnt, auch auf hohem Niveau jammern.

Denn: Wenn eine Alternative zu Paket X fehlt, ist das dann die Schuld des Autoren dieses Pakets? Hätter er/sie/es warten sollen, bis Alternativprojekte auftauchen? Na also.

Ansonsten verwenden wir hier Gentoo und können jederzeit wählen, sofern der/die Autor(en) einer verwendeten Software das zulassen.

Wenn Package Foo mit Alsa und Pulse zusammenarbeitet, aber nicht mit OSS, dann wähle ich Alsa und freue mich. Wenn jemand nun schimpft, sein geliebtes OSS wird nicht unterstützt, habe ich dafür durchaus Verständnis. Aber vielleicht gibt es gute Gründe? (Zum Thema OSS4 fand ich diesen Artikel ganz interessant.) Vielleicht waren der/die Autor(en) und/oder Package Maintainer nur nicht in der Lage für OSS-Unterstützung zu sorgen? Vielleicht fehlen auch einfach das Interesse oder der sichtbare Bedarf?

Es wird gerne vergessen, dass die meisten Projekte unbezahlt sind und durch Opferung persönlicher Freizeit leben. Ich sehe es persönlich auch nicht ein, warum ich meinem QT-basierten Programmen ein GTK3-Interface spendieren soll, wenn a) QT4 ausgezeichnet funktioniert, ich b) GTK3 nicht verwende, und daher c) auch nicht die vielen Stunden dafür opfern möchte. Auch hierfür habe ich also durchaus Verständnis. (Umgekehrt kann ich keinem GTK-Programmierer abverlangen für ein alternatives QT-Interface zu sorgen.)

@avx: Entschuldige bitte, auch wenn du hier Äpfel mit Birnen vergleichst, ist mir natürlich klar, dass ich daran Schuld bin. Ich habe mich da ganz klar zu undeutlich ausgedrückt. Mit "moderner Hardware" meine ich Hardware im Einsatz für Laptop und Desktop Systeme. Dass du im embedded Bereich ganz andere Anforderungen hast, ist natürlich klar. In diesem Fall lohnt vielleicht ein Blick auf LFS oder DiY-Linux. Damit kann man einen funktionsfähigen Linuxserver mit Apache2 auf unter 8MB zusammenpopeln. *LFS Staff wrote:*   

> A few of us have been working on creating a very small embedded LFS system. We installed a system that was just enough to run the Apache web server; total disk space usage was approximately 8 MB. With further stripping, that can be brought down to 5 MB or less. Try that with a regular distribution.

 

@franzf: Ja, aber woher hat er denn diese "Macht"? Siehe fehlende Alternative zu Paket X oben. Wenn Distributoren begeistert auf den Zug aufspringen, dann wird sich eben von ihm abhängig gemacht. Die Frage ist dann, wie kritikfähig oder eben beratungsresistent er am Ende ist. Aber das ist wohl noch abzuwarten.

Aber nun zu einem "Wunder": Mein System ist nun gconf- und gvfs-frei. Ich habe die beim letzten Mal erwähnten Änderungen durchgeführt, und "emerge --ask --depclean" belohnte mich mit dem Rauswurf von fast 30 Paketen. Irre. Ich dachte immer das ganze Gnome-Gedöns sei auch wegen gparted auf meinem Rechner (brauche ich beruflich), aber dem ist nicht so. Fein! Es lohnt sich durchaus ein wenig mit equery auf "Spurensuche" zu gehen.  :Smile: 

----------

