Hanisch schrieb:
Da sollte man aber nicht so tun, als ob alles fehlerfrei wäre und entdeckte Fehler einfach als PEBCAC abtun.
Hast du immer noch keinen Fehler gezeigt, der nicht durch dein Handeln verursacht wurde, und somit eben kein reproduzierbarer Fehler sondern
PEBKAC ist (oder hast du ein Ceyboard?). Meinetwegen auch ein Layer-8-Problem, wenn dir PEBKAC nicht gefällt.
Hanisch schrieb:
Nein, ich wende nur die Features an, die ganz offiziell im System vorgesehen sind.
Genau das ist es, was du NICHT tust. Du installierst vielmehr alles, was nicht bei drei auf den Bäumen ist, um dich dann zu wundern das da etwas nicht so richtig läuft, wenn man doch gerade erst selbst dafür gesorgt hat.
So wird seit jeher in allen Linux-Distributionen das Nachinstallieren weiterer Oberflächen unterstützt.
Es wird auch nichts aktiv dagegen getan, dass du dir Blei ins Trinkwasser mischt. Kannst du jederzeit tun. Blei ist legal erhältlich, Trinkwasser auch.
Deshalb wird das aber nicht unterstützt, es wird nur nicht aktiv verhindert.
Daher halte ich mein Dazuinstallieren z.B. von LXQT (Lubuntu), Xfce oder Budgie zur KDE-Plasma Oberfläche von Kubunu 18.10 nicht für erwähnenswert.
DU nicht, alle anderen schon. Warum? Weil genau DAS die Ursachen für deine Probleme darstellt.
Wo ist jetzt der Unterschied zwischen dir und den anderen? Die anderen haben jahrelange Erfahrung in Problemsuche und Support, du hast jahrelange Erfahrung im Probleme selbst herstellen.
Es ist zu einfach und nicht gerechtfertigt, alles, was vom Mainstream abweicht, als PEBCAC zu brandmarken.
Nein, die Antwort spare ich mir, die würde gegen mindestens eine Forenregel verstoßen.
Allerdings muß ich leider feststellen, daß offensichtlich in den neuesten Implementierungen einiger Distributionen und hier speziell der KDE-Plasma Oberfläche das Problem der Fernwirkungen verschiedener Oberflächen aufeinander nicht ausreichend ausgetestet bzw. implemantatorisch ausgeschlossen wird.
Ja, verdammt. Die Entwickler kommen nicht auf die Idee, völlig hirnrissige Systemkonfigurationen auszuprobieren. Warum sollten sie auch? Dem KDE-Entwickler ist wichtig, dass seine Oberfläche funktioniert. Dem ist es völlig gleichgültig - und das kann es ihm auch sein - ob da ein GNOME-Hintergrunddienst oder sonstwas läuft, der seine eigenen Dienste stört. Das ist nämlich für KDE völlig irrelevant.
Und Du behauptest, daß 'lightdm' unbesehen mit KDE-Plasma zurechtkommt, was ich ja experimentell für den Fall von KDE-Plasma in einer VM widerlegt habe.
Du hast hier nur widerlegt, dass du in der Lage bist, ein sauberes System aufzusetzen. Aber das hast du schon dermaßen oft in so vielen Foren bewiesen, dass dieser erneute Beweis gar nicht mehr nötig war.
Wenn das der Fall ist, dann haben eben die Entwickler diese Fernwirkungen nicht ausreichend berücksichtigt.
Nein, du hast nicht im geringsten verstanden, was du tust. Kein Entwickler kann alle deine seltsamen Ideen der Systemkonfiguration vorhersehen. Wozu auch? Du bist vermutliche der einzige Mensch auf der Welt, der eine solche hinbekommt.
Wir sehen hier den lebendigen Beweis, dass Rick Cook recht behält.
Wieso muß ich als unbedarfter Nutzer, der erlaubte Features anwendet, dann mit Problemen rechnen?
Hm, mal sehen...
Du installierst Dinge, die, wie man aus abertausenden Quellen erfahren kann, nicht zusammenpassen. Und wunderst dich, dass sie nicht zusammenpassen. Wie kann das nur passieren? Un-glaub-lich!
Wieso und weshalb sind nicht alle Features ausreichend ausgetestet?
Siehe oben, Rick Cook. 1989.
Wieso gibt es Sonderkonfigurationen für den Display-Manager für KDE-Plasma? Wo steht das?
Gibt es nicht. Wenn man aber $ALLES_MOGLICHE installiert, das sich in die Konfiguration des Loginmanagers einträgt und mitläuft, dann läuft das nunmal mit.
10 Jahre Linux-Erfahrung? Sind die dir über ein Jodeldiplom der UNEM zugeflogen? Solche Absoluten Grundlagen sollten nach 10 Jahren im Schlaf sitzen.
Es ist ja noch viel schlimmer, denn auch mit dem Standard-Display-Manager 'sddm' gibt es Distributionen, die bei aktiviertem Miniprogramm "Analoge Uhr" mit einem eingefrorenen Desktop reagieren.
Und immer noch gibt es dafür keinerlei reproduzierbaren Beweis...
Gestestet habe ich das mit der Netrunner Distribution (einem Ableger von Manjaro) in einer VM mit den zwei Oberflächen KDE-Plasma und Xfce.
Also weiterhin nicht reproduzierbar auf einem unsauberen System.
Wer weiß, wieviele Distributionen es noch gibt, die mit der KDE-Plasma Oberfläche und beliebigen aktivierten Miniprogrammen in einer VM ähnlich reagieren?
Genau 42. Handverlesen nach Behandlung durch Linux-Professor Dr. Hanisch.
Naja, jedenfalls konnte ich bei den Distributionen Kubuntu, Manjaro und Siduction in einer VM mit 'sddm' anstelle von 'lightdm' das Problem lösen.
Na, warum wohl? Hm, weil der vorher nicht als Loginmanager festgelegt war und dort noch nichts verkonfiguriert war? Nein, streichen wir die Vermutung. Die wäre zu logisch. Das muss an deinen heilenden Händen liegen.
Wenn das offensichtlich das Problem dennoch nicht generell löst, dann ist in der Implementierung von KDE-Plasma für Systeme in einer VM noch etwas anderes faul.
Faul ist hier etwas anderes. Und das ist sehr offensichtlich.
Und daß die Implementierung einer Oberfläche auch für den Einsatz in einer VM gelten muß, habe ich in meinem obigen Posting doch hoffentlich überzeugend dargelegt.
Nein, du hast bisher folgendes logisch und nachvollziehbar dargelegt:
Das du praktisch keine Ahnung davon hast, was du tust, davon aber jede Menge. Und ausdauernd.
Nun, das Bild hat ja auch einen Inhalt. Dieser Inhalt zeigt, daß weder übermäßig Hauptspeicher noch überhaupt die SWAP-Partition genutzt wird.
Und wie das zustande kommt und was da läuft? Genau, gar nix. Vergleichswerte? Fehlanzeige.
Aussagekraft: 0. In Worten: Null.