
Tags:
Linux,
seufz,
Source-MageNach wie vor, ist das große Thema meine Source Mage-Installation. Dafür war das ein Tag zum Abgewöhnen. Ein Problem angerissen, da tut sich auf der nächsten Seite ein neues Problem auf. Denn, da muß ich ausnahmsweise, doch vielen Kritikern recht geben. Es gibt Probleme unter GNU/Linux die einfach in die Kategorie “Fricklersoftware” fallen. Damit ich in ungefähr einer Woche, nach meinem Urlaub bei meiner Freundin in Münster noch weiß, wo die Probleme liegen fasse ich sie hier mal zusammen:
Wo genau das Problem an sich liegt, weiß ich nicht wirklich, denn bis heute wurden beim Bootvorgang die Samba-Shares vom Gateway auch, wie unter Gentoo eingehangen. Aber da beim Bootvorgang, trotz im Init-Prozess aktiviertem Start von Samba dieser Dienst nicht startet werden auch die Shares nicht gemountet. Scheinbar, möglicherweise hat es etwas mit folgender Meldung zu tun:
mountnetwork: mountnetwork: Provider for facility portmap not configured
Denn ein Start von Samba per “telinit”-Command ist nicht möglich, es funktioniert nur über einen restart obwohl, wie gesagt, Samba eigentlich gar nicht gestartet ist
$ telinit list | grep samba
3 samba
.. bedeutet eigentlich, daß Samba in Runlevel 3 gestartet werden soll. Nach dem Boot sind die Samba-Shares von anderen Systemen aus nicht erreicht, was klar bedeutet, daß Samba aber nicht aktiv ist. Ergo: Ein wenig Einarbeitung in das von SMGL benutzte Simpleinit ist wohl gefragt. Ähnliche suspekte Verhaltensmuster hatte ich auch schon bei der Netzwerk-Konfiguration erlebt.
Eigentlich war ALSA mitunter einer der wenigen Dienste, der kaum Probleme machte. Nun sind aber konsequenterweise nach dem Boot-Prozess alle Mixer-Einstellungen auf “Mute“, so daß ich den Sound erst manuell aktivieren muß. Sehr unpraktisch auf Dauer. Auch wenn man das System (im Produktivfall) nur einmal am Tag bootet.
Nach der Installation des proprietären nVidia Graphikkartentreibers sind die Fonts der GTK-Anwendungen aus 10km Entfernung noch lesbar. Was man per Kcontrol, dem KDE-Kontrollzentrum für KDE-Programme bequem ändern kann bedarf scheinbar einer kompletten Gnome-Installation, sofern die GTK-Einstellungen dort überhaupt unter Windowmanagern übernommen werden. GTK-Theme-Switcher bringt nicht die erforderliche Lösung des Problems, genauso wenig wie bisher das Editieren von gtkrc-Files ob systemweit oder im $USER-Verzeichnis. Ja, ich habe eine generelle Abneigung gegenüber Gnome und ja, ich kann GTK2+ wenig abgewinnen, trotzdem gibt es nach wie vor einzelne gute Anwendungen, die besser sind als ihre KDE-Pendanten, weswegen ich nicht darauf verzichten möchte. Aber die Kombination Gnome/GTK läßt sich deutlich schwieriger mit anderen Windowmanagern oder Desktop Environments in Einklang bringen als KDE/QT-basierende Anwendungen. Für mich ist das, neben der unsäglich unbenutzbaren Oberfläche von Gnome, dessen Filemanger Nautilus und grob abweichenden Keybindings gegenüber anderen WM/DEs Killerargumente gegen Gnome. Und das dies nicht die einzigen Aspekte sind ist nichts Neues.
Tja, eine Arbeit, die bei mir zwar relativ selten vorkommt, aber trotzdem zu den ersten Dingen gehört, die ein funktionierendes System benötigt ist das Brennen von CDs. Dafür gibt es unter Linux die CDRtools. Der Maintainer steht seit geraumer Zeit (genauer seit Kernel Version 2.6.8) auf Kriegsfuß mit den Kernelmaintainern. Wer da nun im Recht oder Unrecht ist, ist mir als Anwender dermaßen Latte, das glauben die beiden Parteien gar nicht. Für mich zählt nur, ob es funktioniert oder nicht: Es funktioniert unter Source Mage mit SMGL-Kernel und mit Vanilla-Kernel nicht. Das bedeutet, daß ich als User nicht brennen kann. Dabei findet “cdrecord” keine “Supported Modes” für die angeschlossene Hardware. Als Superuser aka root ist brennen natürlich möglich. In einem allseits bekannten Forum versuche ich nun auf Hilfe zu hoffen. Aber wie zu erwarten bisher nunmal nicht erfolgreich. Am meisten ärgert mich .. nein kotzt mich an, wie der Maintainer der CDRtools sich in Mailinglisten und Newsgroups präsentiert. Wenn ich solche Threads lese und explizit dabei die Beiträge von Jörg Schilling lese, dann ärger ich mich.
- Umstieg auf alte noch funktionierende Linux Versionen
- Umstieg auf Solaris
- Kontaktaufnahme mit den Linux Kerneel Entwicklern und das _Problem_ lösen was bekannten Wirkungen hat…..
Sowas sind nicht die Lösungsvorschläge, die ich lesen möchte, wenn ein Paketmaintainer sich zu Problemen mit seiner Software äußert. Insbesondere nicht dann, wenn schon zu Zeiten von Kernel 2.4.x Probleme mit den CDRtools vorhanden waren. IMHO gibt es Basisanwendungen, die funktionieren sollen und das Brennen von CDs ist keine exotisches Anwendung, so daß es als Anwender ohne root-Rechte eigentlich möglich sein sollte, diese nutzen zu können. Mit DVDs klappts ja auch …
Ach, die Liste des Grauens ließe sich noch beliebig weiter führen. Sei’s nun die nicht erstellten EAP-Files über den EAP Editor oder dem Kommandozeilentool unter e17 was ich durchaus hinnehme, da es eine Software im Entwicklungsstadium ist, genauso wie den ein oder anderen unvorhergesehenen Absturz von e17 oder der CVS Version von Gaim. Aber darauf bin ich ebenso gefaßt, wie auf fehlendes GLX bei nicht vorhandener 3D-Unterstützung. Nur einige dieser Probleme sind nunmal nicht auf dem Mist von SMGL gewachsen, sondern Probleme die mich seit u.a. mehr als zwei Jahren meiner aktiven Zeit als Linux-User unter diversen Distributionen kontinuierlich verfolgen. Es kann doch nicht so schwer sein, einheitliches Verhalten von Oberflächen herzustellen oder auf Vorgänge der Kernel-Entwickler einzugehen, auch wenn man sich dabei auf den Schlips getreten fühlt. Aber so? So ist es kein Wunder warum Linux nach wie vor mangelnde Usability nachgesagt wird. Daran hat nicht die Community und bestimmt nicht der Anwender schuld ..