12.1 RC1 - after installation comment

hzsuse · October 25, 2011, 7:01pm

Ich fühle mich inzwischen als reiner Anwender, nicht mehr als Systemfuzzy.
Mit dem Alter - Rentner - bin ich zudem langsamer und vorsichtiger geworden.
Rein aus dieser Sicht möchte ich das neue System kommentieren.

Was ist besser in der 12.1 RC1:

Im Vergleich zu 11.4:

C++ : verbesserte Warnungen
Drucker Kyocera FS-C5100DN wird automatisch erkannt
Bessere automatische Einrichtung der Installationsrepositories
Anscheinend weit geringere Absturzneigung.

Im Vergleich zu 12.1 Beta:

funktionsfähig - Bildschirmsteuerung (Sony Multiscan 20sfII) funktioniert.

Verschlechterungen:

Im Vergleich zu 11.4 keine nennenswerten, nur:
Fehlermeldung beim Einloggen
“Es wurde kein Touchpad gefunden” (kein Wunder, ich habe keines!)
Unendliche Schleife bei der Installation, sobald “Software” angeklickt wird.

Im Vergleich zu 11.2, 11.3 etc:

Kein Aufwachen nach “Tiefschlaf” - wie in 11.4

Ansonsten i.w. alles wie früher, d.h.

fast alle Bedienungsschwächen des Systems wurden beibehalten,
designorientierte Spielereien wurden weiter ausgebaut.

Beibehalten wurden fast alle so kleinen wie zeitraubenden Schwächen:

Bei der Installation:

Sprachauswahl bei der Installation nur ganz am Anfang
(na gut, das macht man beim ersten Installationsversuch i.d.R. richtig)
Akzeptieren des Partitionierungsvorschlags führt zur Zerstörung von Userdaten (Formatierung der Userplatte!!)
Vorschlag für Bootmenu: führt zum Nichterkennen anderer Systeme!
Auswahl eines geeigneten Bootmenus leidet unter erbärmlicher Benutzerführung
(u.a. Inkonsistenz in Übersetzung Buttonbeschriftung/Hilfestellung: “weitere” <==> “andere”)
Begriffe wie “Zusammenführen” und Chainloader(und noch mehr das deutsche Pendant) werden nicht angemessen erklärt
Mein Vorschlag:
[LIST]
Erkennen und Zusammenführen bzw. Chainloader als Default
Um automatische Installation zu ermöglichen: “Schalten Sie jetzt Drucker und USB-Scanner ein und aktivieren Sie ggf. den Internetzugang”
Userpartition nur dann vorschlagen, wenn kein weiteres Linux-System vorliegt
auswählbare Parameterklassen, u.a. nach Zweck und Leistungsfähigkeit des Systems (Spielmaschine? Handwerkerlaptop?)
abgesicherte Sicherungs- und Übernahmemöglichkeit von System- und Userparametereinstellungen in ein neu installiertes System
(das Kopieren von Dot-Dateien wie .kde4 kann zu Systemversagen führen!)

[/LIST]

Nach wie vor nervig:

Audio- und Videoaktivierung grotesk und wg. Versteckspiel (u.a. KMix!) langwierig.
Parametereinstellungen in KDE(±Tools), Gimp, Audio etc. erfordern Tage und umfangreiche Detektiv- und Versuchsarbeit
Kaum ein Parameter ist selbsterklärend benannt oder wird zumindest verständlich erklärt
(klar, die, die immer damit zu tun haben, merken das nicht).
Selbst für altgediente DVer wie mich hat kaum ein Parameter die zuerst vermutete Wirkung
Nachrangige Parameter wie z.B. die für Fenster- und Hintergrundgestaltung sind leicht zu finden, liegen quasi in der Auslage, fast alle wichtigen sind genial versteckt
Übliche Hacker-Aussage “nur 5 Sekunden”, tatsächlich nötig Stunden bis Tage, bis alles ‘wie zuvor’ funktioniert.
Update würde dies weitgehend vermeiden. Früher habe ich zum Entsetzen meines damaligen Sysadmin immer Update statt Neuinstallation gemacht.
Das führte gelegentlich zu schweren Fehlreaktionen bis zur Funktionsunfähigkeit des Systems (von Entwicklern übersehene Inkompatibilitäten).
Bei der heutigen Plattengröße gebe ich kein lauffähiges System leichtfertig auf.

Arbeitsfläche:

extrem störende Randaktionen, Ausschalten erfordert Detektivarbeit sowie Ändern von Parametern in zwei Kontexten
Directory als Symbol nicht benennbar
(ich habe u.a. 2 Symbole 2011)
Umbenennung jetzt möglich - benennt aber die Directory um!

KDE:

gefühlt tausend Parameter sind einzustellen
die Wirkung der Parameter mangels verständlicher Doku nur experimentell erfahrbar
default-Parameter überlasten alte Rechner bis fast zum Stillstand
sehr umfangreiche Parametereinstellung nötig bis zu brauchbarer Arbeitsumgebung

Gimp:

immer noch sind die RAW-Tools gesondert einzufahren
sonst falsche Gimp-Fehlermeldung ungeeignete Tiffs

Thunderbird:

bei jedem Start neuer Tab “Willkommen zu Thunderbird”
ich kenne Otto Normalos als Linuxuser mit -zig offenen dieser Tabs

Dazu kommen im ganzen System teils asymmetrische Aktionen zum Aktivieren und Deaktivieren.
Das nimmt schon XPtreme Ausmaße an!

Vorschlag:

zentrale Einstellung aller Parameter, Vorbild “about:config” in Firefox
nur nicht so genial versteckt wie dieses “about:”!
dazu automatische Sicherung von Parametereinstellungen
Gründe dafür gibt es übergenug:
[LIST]
Für Anwender sind Reaktionen oft nicht ausreichend zuordenbar.
z.B.: Parameter von KDE, Dolphin, Arbeitsfläche oder irgend etwas anderem?
Das Verhalten z.B. der Arbeitsfläche ist vom Fensterverhalten nicht abgrenzbar
(“keine Randeinrastzone” - immer noch Vergrößerung, wenn Fenster den Rand trifft).
immer mal wieder “verliert” oder vermostet ein Programm seine Parametereinstellungen
(Skype!! Firefox! Gimp. Bei anderen wie KDE geschieht das selten)

[/LIST]

Und noch ein Vorschlag für die 13.1:

Konzentration auf Verbesserung und damit Vereinfachung der Benutzerschnittstelle sowie brauchbare Fehlermeldungen statt wilde Gimmick-Vermehrung (wie in KDE4)
Hinweis: die log-Files mögen für Systemprogrammierer unentbehrlich sein - mit ihrer hohen Zahl an irrelevanten Fehlermeldungen und Warnungen, die zudem weitab von der Benutzerwelt liegen, als Instrument für Anwender nahezu völlig wertlos.
Z.B. sind beim Unix-Dateikonzept Hinweise auf Inodes statt auf Dateinamen zwar verständlich, aber praktisch immer nutzlos.

Natürlich wäre noch (weniger und) mehr nötig, um Marktführerschaft zu erlangen.

nein, nicht neue Tools - Linux hat mächtige und unzählige
leider verstecken sich viele Tools unter kryptisch-nichtssagendem Namen
befleißigen sich einer von hohem Individualismus geprägten Beschreibung
haben sie keine gemeinsamen Schnittstellen, wenn man vom beschränkt brauchbaren Pipe-Konzept absieht
fehlt die Kompatibilität vieler Linux-Tools selbst innerhalb der aktuellen Linux-Varianten

hzsuse · October 25, 2011, 11:21pm

Ergänzung:

Ach ja, ich habe noch weitere leichte, aber höchst ärgerliche “Verböserungen” in der 12.1 RC1 gefunden:

LibreOffice: unteren Fensterbalken schieben gelingt nur bei Drücken des mittleren Mausknopfs (habe keine Rückstellung auf seitheriges Verhalten gefunden)
Wer das noch nicht ‘erhackt’ hat, vermutet einen Programmdefekt.
Solcherlei unbegreifliche Bedienungsänderungen kommen in neuen Linux-Distros immer wieder vor und erschweren flüssiges Arbeiten.

Dolphin:

“editierbare Adreßleiste” muß mit “Werkzeugleisten einrichten” ausgewählt werden
Das reicht aber nicht, das ist bei jedem neuen Fenster einzustellen, sonst sieht man etwas, was als “Verknüpfungsansicht” apostrophiert wird
Die “Verknüpfungsansicht” zeigt eine sinnfreie Geräteangabe, bei mir “1,3 TiB Festplatte” (ich habe mehrere gleich große!)

Verbesserung: Das Fenster “Arbeitsplatz” zeigt wieder wie früher den Pfadnamen an statt z.B. “1,3 TiB Festplatte”.

Bemerkung:
Es wäre höchste Zeit, wie in Dosensystemen Partitions zu benennen und anzuzeigen
Das würde die Arbeit mit dem Partitionierer während der Systeminstallation etwas weniger zum Glücksspiel machen.
Es ist lästig und gefährlich, wenn die Platten während der Systemgenerierung nicht zuverlässig angesprochen werden können.
Bisher besteht die einzige sichere Abhilfe darin, alle Partitions unterschiedlich zu partitionieren (z.B. Platte 1, erste Part.: 31 GB, Platte 2: 32 GB usf.)

Besonders gefährlich ist das dann, wenn Änderungen mit dem Partitionmanager gemacht wurden
Z.B. Tausch von Windows- und Linux-Userpartitions unterschiedlicher Größe - das kann alle Bezeichnungen durcheinander wirbeln und Linux funktionsunfähig - schnellste Abhilfe mittels Neugenerierung.
XP hingegen funktioniert klaglos weiter, egal, wo z.B. seine D- und E-Partition liegen, selbst die C-Partition läßt sich mit überschaubarem Aufwand verlagern.

Ein Change Management wie es das an allen Großrechnerbetriebssystemen gibt würde solcherlei groben Unfug abstellen, auf gleichartige Bedienung gleicher Leistungen bestehen und Unsinn wie programmspezifische Dateiauswahl bei Laden und Sicherung abstellen (Zwang zur Nutzung von Standardprogramme für solche Zwecke!).
Bisher haben selbst die Grundprogramme von KDE oft für Gleiches unterschiedliche und deshalb bedienungsfeindliche Menuführung (Dolphin und Konqueror schon im Datei-Menu bzw. bei der Zuordnung derselben Leistung zu unterschiedlichen Pulldown-Menus).
Die Häufung solcher gering erscheinender unbegründbarer Bedienungsunterschiede macht Linux bedienungsunfreundlich.

OpenSuSE könnte die Erstellung einheitlicher Tools anleiern und sich damit, einheitliche Abwicklung gleicher Aktionen durch Verwendung dieser Tools zu fordern, bleibende Verdienste erwerben - und sinnlos “kreative” Entwickler durch bevorzugte Auswahl konformer Software in ihre Schranken weisen.
Das sollte möglich sein - kaum ein Entwickler dürfte z.B. Wert darauf legen, die 9573. schlechte Variante zur Abfrage des Sicherungsziels zu erstellen, wenn ein kodierter benutzungsfreundlicher Standard bereitsteht.

hzsuse · October 29, 2011, 9:26pm

Neu entdeckter Fehler:

Dolphin:

“Auswahl umkehren” ist in der 12.1 RC1 unbrauchbar
[LIST]
Bisher: Auswählen aller Subdirectories, dann Umkehr der Auswahl: alle einfachen Files des Directories sind ausgewählt
Jetzt: nach Auswahl umkehren sind alle Files und Directories ausgewählt
Wurde zuvor “alle auswählen” verwendet, sind jetzt nach “Auswahl umkehren” alle einfachen Files weiterhin ausgewählt, nur nicht die Directories
Ich halte das für einen offensichtlichen groben Maintenance-Fehler.
Im Rahmen der unverzichtbaren internen Funktionskontrolle vor Auslieferung sollte die Grundfunktionalität standardmäßig überprüft werden
Werden dabei solche einfach erkennbaren Fehler nicht bemerkt, halte ich eine Revision der Auslieferungskontrolle von Dolphin (bzw. KDE) für erforderlich
Sollte es sich jedoch um eine beabsichtigte Änderung handeln, würde Dolphin damit seine bisherige Tendenz zu spontanen inkompatiblen Änderungen fortsetzen.
In diesem Fall hielte ich dieses Programm für fehlgepflegt und als Grundprogramm innerhalb von KDE für nicht tolerabel

[/LIST]

Linuxsusefan · October 29, 2011, 10:44pm

@ hzsuse,

in allen ehren was Du hier machst, wäre es aber nicht besser Du eröffnest für das alles entsprechende Bugreports so das Entwickler davon Kenntnis erlangen und darauf reagieren können? Hier lesen die Entwickler wohl eher nicht mit. Wenn auch ich nicht sicher bin, so wage ich das stark zu bezweifeln das jene dies tun, da die Entwicklungsarbeit bekanntermaßen in englischer Sprache stattfindet. Freilich kannst Du das hier weiter mitteilen, aber um effektiv Abhilfe zu schaffen sind Bugreports die bessere Lösung. Oder meinst Du nicht?

hzsuse · October 30, 2011, 4:05pm

Im Prinzip ist das völlig richtig.
Aber dies würde die Entwickler überfordern.

Ich war früher mal als Entwickler tätig.
Als solcher war ich darauf angewiesen, daß das, was ich vorgesetzt bekam, hinreichend voranalysiert und kondensiert war.
Entwickler, also die eigentlichen Adressaten von Fehlermeldungen, müssen abgeschottet werden, um zu ihrer eigentlichen Arbeit zu kommen.
Es sollte also Gruppen von Leuten geben, die Fehlermeldungen vorprüfen und ggf. an die vermutlich Zuständigen weitergeben.
Selbst perfekte Vorarbeit kann übrigens nicht verhindern, daß der Entwickler einen Teil der zugestellten Fehlermeldungen weiterleiten muß.

Eine Zeitlang war ich dafür zuständig, Fehlermeldungen vorzuanalysieren und an einen Entwickler weiterzuleiten.
Manchmal hielt sich der Entwickler für unzuständig. Manchmal hatte er recht, aber öfter mußte ich ihn überzeugen, daß der Fehler wirklich bei ihm lag
(ein Nachweis aufgrund von Systemspezifikationen und/oder Schnittstellenexegese kann ganz schön aufwendig sein!).

In meiner Zeit als Entwickler hatte ich einen Tag lang die Gelegenheit, Endabnehmer direkt zu beraten.
Das war sehr interessant.
Es zeigte sich jedoch, daß dies aufgrund des großen Abstands denkbar ineffizient war.

Ich behaupte mal, daß eine direkte Kommunikation zwischen Endanwender und Entwickler unter den heutigen Bedingungen - sehr viele Anwender! - nicht zielführend ist.

Es braucht genau eine Ansprechstelle für Endanwender
Diese muß
[LIST]
dem Benutzer bekannt sein
in der Lage sein zu klären ob ein Fehler vorliegt
wissen, an wen dieser zur weiteren Behandlung zu leiten ist
beiden Seiten als zuverlässig gelten

[/LIST]

Für so eine Aufgabe kommt eigentlich nur der Systemdistributor in Frage.
Als Alternative ist Teilautomatisierung mittels einer datenbankgestützten “intelligente” Softwarelösung denkbar.
In diesem Fall müßte jeder Softwareanbieter, den der Distributor stützt, geeignete Hinweise geben, wofür er sich zuständig fühlt, und diese Hinweise müßten anhand von Fehlzuordnungen automatisch bzw. manuell verbessert werden.

Im Rahmen des Mozilla-Fehler- und Änderungsrahmenwerks habe ich im Lauf einiger Jahre etwa hundert Fehlermeldungen und etwa ein Dutzend Änderungsanträge eingebracht. Über die Hälfte meiner Fehlermeldungen erwies sich als neu. Alle Meldungen wurden zufriedenstellend abgehandelt, mit Fehlerbehebungszeiten von 2 Wochen bis 3 Jahre bis zur Integration in einen Prerelease (normalerweise 2 bis 6 Monate).
Die Meldungen werden zuerst durch einen Bearbeiter vorgeprüft und einem Tool bzw. schon einem Entwickler zugeordnet.
Im Laufe der Bearbeitung wird man regelmäßig informiert und manchmal um weitere Mitarbeit gebeten.
Durchschnittlich rechnete ich für eine Fehlermeldung oder einen Änderungsantrag mit zwei Mannwochen eigenem Aufwand, aber dies war dank der stringenten Behandlung sinnvoll.

Leider fehlt dafür bei Linux im Gegensatz etwa zu Mozilla (Firefox, Thunderbird, Seamonkey, XULrunner, Mozilla Suite, Bugzilla, …) das für eine einheitliche zielgerichtete Abwicklung erforderliche zentrale Rahmenwerk.

Sehr oft ist ein zweckmäßiger Empfänger einer Meldung, wenn überhaupt, nur mit Aufwand eruierbar;
wenn eine Fehlersituation nur im Zusammenspiel mehrerer Tools auftritt, erscheint jeder Versuch dazu als zwecklos.

Gelingt es, bis in Entwicklerkreise vorzudringen, ist manchmal - insbesondere bei US-Entwicklergruppen - erst eine langsame Annäherung mit Einfühlen in die jeweiligen Empfindlichkeiten unter Absonderung von Ergebenheitsadressen nötig. Das direkte Einbringen einer Fehlermeldung kann durchaus zum Flaming bisfühbisren.

Die einzelnen Linux-Entwicklergruppen pflegen also sehr heterogene, z.T. wenig zielführende Stile, selbst wenn sie Bugzilla einsetzen.
KDE etwa fordert nach Absturz zu einer Meldung auf. Geht man dem nach, stellt sich heraus, daß dies nicht zielführend ist.
Man soll die Umstände, die zum Auftreten des Fehlers geführt haben, beschreiben - aber es wird u.U. keinerlei Plattform dafür geboten.
Man wird gebeten, Debugsoftware einzuspielen - für künftige Wiederholungen. Andere Fehler als die, die zu Absturz führen, erscheinen mir bei KDE als nicht meldbar, selbst bei strikter Wiederholbarkeit.
Es erscheint mir zweifelhaft, ob Fehlermeldungen überhaupt erwünscht sind.

Fehlermeldungen zu einer neuen Linux-Version wären zweckmäßigerweise zuerst einmal vom Systemanbieter vorzusortieren, hier also von OpenSUSE.
Ohne unterstützende Software wie Bugzilla wird sich soetwas nicht sinnvoll organisieren lassen.
So eine Meldungsverwaltung könnte so nebenbei den Blick für aktuellen Systemzustand schärfen.

Ich sehe leider nicht, daß OpenSuSE so ein Framework bereithält.
Vielleicht wäre eine Zusammenarbeit verschiedener Distributoren noch besser.

Die Qualität eines Betriebssystems wird letztlich durch die Qualität der Fehlererfassung und Fehlerverfolgung limitiert.

martin_helm · October 30, 2011, 4:19pm

Diese Vorsortierung findet doch genau dadurch statt, dass man Fehler in
https://bugzilla.novell.com berichtet und nicht mühsam für jedes Paket den
passenden Upstream heraussucht.

hzsuse · November 1, 2011, 8:06pm

Sie haben recht, und das ist derzeit auch der beste Weg.
Mich trifft, daß ich das übersehen habe - obwohl ich dieses Angebot schon genutzt hatte.

Im Fall eines Absturzes wird z.B. von KDE leider eine Fehlermeldung an https://bugzilla.novell.com vorbei angeboten.
Wohl deshalb habe ich vergessen, daß es diesen eindeutig besseren Weg gibt.
Daran hätte ich nämlich denken müssen.
Habe nämlich mindestens zwei Meldungen an https://bugzilla.novell.com gesandt.
Vermutlich hat mich beim letztenmal der Ärger über die automatisch angebotene “Fehlermeldungsbehandlung” von KDE vergessen lassen, daß ich nach sinnlosen Bemühungen doch noch eine Fehlermeldung absetzen konnte.

Das letztemal war es eine Meldung zu Gwenview.
Enthielt ein Dir jpeg’s und tiff’s, sollten alle angezeigt werden, kam zuerst aber ein jpeg, stürzte Gwenview ab.
Eine klarere und einfachere Fehlersituation gibt es selten.
KDE präsentierte ein Fenster und bat um Ausfüllen und Absenden.
Es wurde vorangestellt, daß der User später eine Beschreibung der Umstände liefern und sich deshalb die fehlerauslösende Situation einprägen solle.
Diese Beschreibung konnte nicht abgegeben werden, stattdessen moserte die Software, die Absturzursache sei mangels Einbindung der Debugumgebung nicht auswertbar.
Gut, die hätte ich zur Not installieren können - an einem anderen Tag.
Nachdem ich trotzdem fortsetzte, erfuhr ich, daß die Meldung nicht bearbeitbar sei.

Zu diesem Zeitpunkt wäre vielleicht schon die automatisch generierte Rückantwort “der Fehler ist bereits gemeldet, er wird demnächst behoben” möglich gewesen.

Eine Bitte um Mitwirkung bei einer Fehlermeldung wegen eines Absturzes halte ich für sinnvoll:

für die Suche nach unbekannten Fehlern - aber nur, solange diese unbekannt sind, oder
wenn der gesuchte Fehler so sporadisch auftritt, daß ihm nicht auf andere Weise beizukommen ist
wenn die eventuell benötigte Dumpinformation vorliegt
wenn die Mitwirkung ernsthaft genutzt wird
wenn die Anfrage unterlassen wird, sobald der Fehler hinreichend analysiert ist

Ansonsten werden User veralbert, und den Entwicklern droht eine Sintflut an sinnlosen Meldungen.

Eine Reihe von Fehlermeldungen habe ich übrigens u.a. deshalb nicht gemacht, weil ich

zuvor eine login-Berechtigung beim jeweiligen Softwareanbieter einholen hätte müssen
das Paßwort vergessen hatte und danach
der Fehler durch Weiterarbeit in der Zwischenzeit nicht mehr reproduzierbar war oder
ich die Situation wegen des zeitlichen Abstands nicht mehr genau genug beschreiben hätte können

Ich hielte es für eine gute Idee,

zumindest die wesentlichen Zulieferer für OpenSUSE auf die obige zentrale Fehlermeldungsbehandlung zu beschränken, also darauf hinzuwirken, daß die Entwickler keine Schleichwege daran vorbei anbieten
(zugegeben, manche Entwickler schätzen das nicht, weil Fehler extern dokumentiert werden)
User, soweit sie zu dieser Unterstützung bereit sind, bereits bei der Installation des Systems in das Fehlermeldungssystem einzubinden (Login-Berechtigung)

hzsuse · November 7, 2011, 6:14pm

Zwei Tage lang habe ich vergeblich versucht, PulseAudio bzw. skype dazu zu bringen, das Mikrofon meines Logitech B500 korrekt zu bedienen.
Nach diversen Versuchen, u.U. zusätzlicher Installation des PulseAudio-Lautstärkenreglers pavucontrol, ist es mir immerhin gelungen

festzustellen, daß das Mikro des B500 überhaupt irgendetwas tut, und bald darauf,
unverständliches Gequäke von der Mikro-Aufnahme zu hören (viel zu schnell, viel zu hoch - ich vermute mono als stereo interpretiert)

Nach einem Absturz heute, unter Verlust der Einstellungen aktiver Programme (u.a. skype und Firefox) tut skype plötzlich (na hoffentlich bleibt das jetzt so!).
Alle angezeigten Einstellungen sehen jetzt übrigens noch immer bzw. jetzt wieder genauso aus wie vor dem Absturz aus.

Während ich diesen Text hier schreibe, versuchte ich nochmal die Reaktion von Skype.
Wieder höre ich nur Quäken.
Dann ein Restart von Skype. Da war überhaupt keine Mic-Eingabe zu hören.
Dann pavucontrol - stummschalten und nach ein paar Sekunden wieder laut - und alles klappt bestens.

Da hat sich anscheinend nicht viel getan seit dem 4.1.2010, siehe Pavucontrol | The Linux Experiment …
“Head over to the Configuration tab, and start choosing different profiles until you can hear some audio from your system. Also, I found that most of these profiles were muted by default – you can change that on the Output Devices tab. If one of the profiles works for you, congratulations! If not, well, I guess you’re no worse off than you were before. I warned you that this was that kind of post.”

Dem obigen Vorschlag war ich zuerst gefolgt, bis ich wenigstens ein Quäken hörte.

Wenn die Sache nicht von Anfang an tut, kann man allem Anschein nach kaum etwas anderes tun als alle - wirklich alle! - Möglichkeiten, einschließlich aller Kombinationen von Parametern mehrfach durchprobieren.
Nicht zu vergessen ist dabei, einige mal alle möglicherweise relevanten Dot-Files zu löschen und hie und da einen Neustart einzufügen.
Wenn dann immer noch nichts, aber auch gar nichts davon klappt, heißt das noch längst nicht, daß z.B. irgendeine absurd erscheinende Aktion zufällig zum Erfolg führt.

Das Ganze hat mit dem, was früher unter Datenverarbeitung verstanden wurde, herzlich wenig zu tun.

Immerhin habe ich es sogar wieder geschafft, meinen Bildschirm auf 1600x1200 einzustellen - ein Programm von mir (und diverse meiner Daten) erfordern das (OpenGL verreckt über kurz oder lang, wenn nur 1280x1024 zur Verfügung stehen). Obwohl das per default eingestellt ist, muß ich das allerdings in der 12.1 RC meist(nicht immer) nach login / Ruhestand neu einstellen.

Als Resume bleibt festzuhalten: Ton und Bildschirmanzeige in Linux bleiben auch in der 12.1 die Achillesfersen von Linux.
Wer Glück (dazu gehört insbesondere neuere, aber nicht zu neue Hardware) und deshalb kein Problem damit hat, soll sich freuen.
Aber solange das so bleibt, werden die meisten Normaluser zurecht einen weiten Bogen um Linux machen.

Als positiv bleibt für mich zu vermerken, daß in der 12.1 RC1 (nach allen bisherigen Updates) erstmals für mich ALSA und PulseAudio nicht ausschließlich fehlfunktionieren.

hzsuse · November 7, 2011, 7:43pm

Nächster Fehler in 12.1RC1 : LibreOffice: “vergißt” definierte Namen …

1.Schritt: diese Variablendefinitionen sind zwar vorhanden, werden aber nicht ausgewertet, bei Aufruf #NAME?
2.Schritt: diese Variablendefinitionen werden beim Abspeichern in eine neue Datei nicht übernommen, also komplett vergessen
(habe ich schon gehabt, aber noch nicht reproduziert)

Mit diesem Fehler darf LibreOffice nicht in der ‘stabilen’ 12.1 ausgeliefert werden!

hzsuse · November 8, 2011, 12:38am

Nach Neustart des Systems funktioniert ersteinmal keinerlei Ton.
Die Eingabegeräteliste (angezeigt von Phonon) ist wieder einmal völlig leer.
Nach den üblichen absurden Aktionen - mehrfaches Ein-/Ausschalten alles dessen, was möglich ist (also nur Ausgabe, Eingabegeräteliste ist ja leer!) ist die von pavucontrol angezeigte Geräteliste wieder o.k. und meine Eingabe wieder als quäkende Geräusche zu hören.

Von mehreren hundert Skype Test Calls sind jetzt etwa ein halbes Dutzend korrekt abgelaufen, aber nach jeder Unterbrechung (Ruhezustand, Neustart) gibt es dasselbe indeterministische Verhalten.

hzsuse · November 8, 2011, 12:54am

Diesen Fehler habe ich inzwischen näher angesehen und eine Fehlermeldung an LibreOffice abgesetzt.
Eine Umgehung ist durch Vermeidung der Definition von Namen, die Bezug aufeinander nehmen, möglich
(z.B. Dialog “Einfügen - Namen - festlegen”)
Achtung: Spreadsheets können durch diese Umgehung deutlich schlechter maintenierbar werden, diese Umgehung sollte ein temporärer Notbehelf bleiben.

hzsuse · November 8, 2011, 11:27am

Nach Ausschalten von PulseAudio
(siehe https://support.skype.com/de/faq/FA10964/Wie-kann-ich-meine-Audioeinstellungen-anpassen-damit-Skype-fur-Linux-funktioniert )
lassen sich die Audio-Geräte in Skype ähnlich wie in früheren Versionen konfigurieren.
Ersteinmal ergab das wieder quäkende Ausgabe, aber nach einigem Herumprobieren habe ich jetzt eine Einstellung gefunden, die möglicherweise nicht nur für den Moment funktioniert. Der Ton war besser als je unter PulseAudio.

Zu früh gefreut.

Skype beendet, .skype zur Sicherheit kopiert, Skype wieder gestartet - der Horror beginnt wieder.
Erster Test Call: kein Echo der Mikro-Eingabe.
Zweiter Test-Call: Quäken, diesmal recht deutlich, ich bin mir jetzt sicher, daß meine Mono-Eingabe als Stereo-Eingabe interpretiert wurde und deshalb doppelt so schnell in doppelter Höhe abgespielt wurde

Also, wenn die ausgelieferte Version der 12.1 genauso vermostet sein wird … na, ich habe ja noch die recht instabile 11.4 zur Auswahl …
… und immer noch habe ich dank wenig hilfreicher Anzeigen keine Ahnung, was kaputt ist, ob und wenn ja wie das Ganze mal funktioniert oder nicht, ist anscheinend rein zufällig.
PulseAudio ist dem Anschein nach nicht ursächlich, verschärft jedoch das Problem durch das Wegblenden von Einstellungsmöglichkeiten.

Allen denen, die warten können, empfehle ich, erstmal einen weiten Bogen um die 12.1 zu machen.
Insgesamt erscheint mir die Version zwar als deutlich stabiler als die 11.4, sie ist jedoch in Bereichen, von denen ich eigentlich nur den Erhalt der Basisfunktionalität erwarte (Audio-Bereich!!, LibreOffice, Bildschirmdarstellung) allzu unausgereift.

martin_helm · October 30, 2011, 4:19pm

Diese Vorsortierung findet doch genau dadurch statt, dass man Fehler in
https://bugzilla.novell.com berichtet und nicht mühsam für jedes Paket den
passenden Upstream heraussucht.