Client - bessere Linux-Integration

Hallo,

ich sehe bei der Linux-Integration des Clients Verbesserungspotential :slight_smile: Ich nutze die virtuellen Desktops unter KDE intensiv. Virtuellen Desktops gegenüber verhält sich der Client komplett agnostisch. Auch die Sache mit dem Systemtray klappt nicht wie man es erwarten würde. Warum die Systembenachrichtigungen nicht genutzt werden kann ich mir hingegen vorstellen. Die Popus sollen ja Funktionen tragen, die sich sonst nicht unter allen Desktopenvironments umsetzen lassen.

Hier eine Zusammenstellung der Problemchen:

Schliesst man den Client, dann bleibt er, wie man es erwarten würde, im Tray aktiv. Allerdings werden dann auch keine Popups mehr angezeigt.

Hat man den Client auf einem Desktop offen, dann werden Popups nur auf diesem desktop angezeigt. Ist man auf einem anderen Desktop sieht man nichts.

Ist der Client nicht im Vordergrund bleiben auch die Popups im Hintergrund. Das ist nicht der Sinn der Popups.

Ist der Client minimiert werden die Popups auch nicht angezeigt.

Jetzt bitte nicht schreiben: Wir testen/unterstürzen nur mit Ubuntu. Das ist an sich schon ein Fehler. Es sollten auf jeden Fall die drei verbreitetsten Desktop-Environments (Cinnamon, KDE, Gnome) getestet und unterstützt sein.

Matthias

Hallo @mahescho,

Wir unterstützen nur Ubuntu. :wink:

Warum?

Jede einzelne Platform (Desktop Environment, Betriebssystemversion, etc.) erhöht den Testaufwand enorm, da man ja immer wieder alle Funktionen des Clients auf allen Plattformen durchtesten muss.
Und da sehr viele Funktionen mehr oder weniger mit Hardware interagieren, lässt sich das ganze nur sehr schlecht bis gar nicht automatisieren.

Als Beispiel ein unvollständiger Auszug aus unserer derzeitigen Testmatrix:

Windows

  • Windows 10 (64 bit)
  • Windows 10 LTSC (32 bit)
  • Windows 10 insider preview (64 bit)
  • Windows 8.1 (64 bit)
  • Windows 7 (32 bit)

Windows Server

  • Server 2008 R2
  • Server 2019

macOS

  • 10.12
  • 10.15

Ubuntu

  • 16.04 LTS
  • 18.04 LTS
  • 20.04 LTS

Android

  • Android 6
  • Android 10
  • Android 11

iOS

  • 12.4.x
  • 13.x
  • 14.x

Mehrere Distributionen und/oder Desktop-Environments vollständig zu unterstützen steht in keinerlei Verhältnis zur Anzahl der Installationen.

Deshalb müssen wir uns auf eine Platform konzentrieren und dort sicherstellen, das der Client “gut genug” läuft - das bedingt auch Annahmen über bestimmte Systemkonfiguration oder Dienste (z. B. Pulseaudio zur Auswahl der Audiogeräte, etc.)

Ich weiß, das ist nicht die Antwort die du hören wolltest, aber ich hoffe ich konnte dir die Gründe für dieses Statement verständlich machen.

Grüße,
Jan

Danke, aber ich bleibe dabei. Ubuntu-Support ist kein Linux-Support sondern Ubuntu-Support und Ubuntu ist nicht Linux. Es sollte auf den drei verbreitetsten Desktop-Environments (Cinnamon, KDE, Gnome) ordentlich laufen und das tut es (ich habe mal kurz getestet, auch mit Cinnamon) nur unter Gnome. Gnome (Ubuntu verwendet diese Usabilitykatastrophe [meine Meinung]) ist sicher ein erster Schritt in die richtige Richtung, aber eben nur ein erster zum Linux-Support.

Kuriosität am Rande: Der Client verwendet QT läuft aber unter KDE nicht richtig …

Meiner Meinung nach ist es auch wenig sinnvoll drei LTS-Versionen zu unterstürzen. Sinnvoller wäre es, es so zu handhaben wie die Distributionen selbst. Es gibt bei Erscheinen der Distribution immer einen Feature-Freeze (Backports ausgenommen) und nur noch Sicherheitsupdates.

2 Likes

Hallo Jan,

Bitte überdenkt dies einmal. Linux ist nicht Ubuntu allein. Mir ist klar, das Ihr nicht ALLE Distributionen unterstüzen könnt, aber Euer Client sollte zumindest zusätzlich auf einem aktuellem Debian und OpenSuSE laufen.

LG Maik

Ich vermute mal, Pascom wertet das recht genau aus, welches OS wie häufig verwendet wird und konzentriert sich wie @jlorenz schon schrieb auf die Versionen mit der größten Verbreitung.

Wie ich schon geschrieben habe ist die Distribution nicht das ausschlaggebende. Wichtig wäre, dass sich der Client in die drei wichtigen Desktopenvironments (Gnome, KDE, Cinnamon) gut integriert. Legt man sich auch Ubuntu fest, dann hat man halt nur Gnome.

+1 für mahescho. Ich selbst verwende neben Windows KDE Neon, das auf der LTS von Ubuntu aufbaut. Die nächste wichtige Plattform ist für uns IGEL OS für Thin Clients, das ebenfalls auf Ubuntu basiert. Die Wahl von Ubuntu als unterstützte Linux Distribution ist meiner Meinung nach also sicherlich richtig. Hier allerdings nur die Standard-Distribution zu unterstützen, und dabei die Oberflächen komplett auszublenden, ist auch meines Erachtens nach der falsche Ansatz. Dass man hierfür die gesamte Testbatterie adaptiert, wäre aber vermutlich gar nicht notwendig. Wenn jeweils ein Entwickler auf einer der großen Desktopumgebungen arbeiten würde, wären die gröbsten Bugs sofort gefunden (und vielleicht auch gleich behoben). :wink:

Hallo zusammen,

aufgrund des andauernden Feedbacks sowohl hier im Forum als auch im Support haben wir uns entschieden die Distributionsart des pascom Clients zu überdenken.

Wir werden hierzu Snap evaluieren und überlegen, in Zukunft den Client als snap anstatt .tar.gz auszuliefern. Das sollte den Großteil der Kompatibilitätsprobleme mit den verschiedenen Distributionen beseitigen.

Wer von euch wäre denn bereit dieses Client-Snap zu testen?

Grüße,
Jan

Hallo Jan,

da ich „den Stein quasi zum Rollen gebracht habe“ werde ich gerne für Euch testen…

LG Maik

Schlimmer geht’s immer :slight_smile:

Das Problem ist nicht das TGZ. Das Problem ist die schlechte Integration in die Desktopenvironments. Wenn das unsägliche Snap die Notifications und die Unterstützung für virtuelle Desktops unter KDE etc. besser macht, OK, ansonsten bringt es nichts.

Hallo @mahescho,

Doch, das ist das Problem, weil es das sehr schwierig macht, den Client auf anderen Distributionen als Ubuntu überhaupt zum laufen zu bekommen, da einfach gewisse Libraries in gewissen Versionen vorhanden sein müssen. Dieses Problem versuchen wir zu lösen. Das könnte evtl. zu einer höheren Verbreitung des Clients unter diversen Linux Desktops führen, was dann wiederum einen Grund liefert sich solche Schönheitsfehler näher anzusehen. :wink:

Grüße,
Jan

OK :slight_smile: Aber :smiley: Das sind keine Schönheitsfehler, sondern eher echte Usability-Probleme …

Am Rande: ich bin kein Freund von diesen neuen psseudo Paketformaten wie Snap. Es gibt DEB und RPM und das reicht völlig. OK, es gibt noch ein paar Exoten, aber eben Exoten. (Ich spüre den Shitstorm heraufziehen :slight_smile: )

Selbstverständlich teste ich Snap mit, keine Frage !

Noch mal ausführlicher zu den Problemen um die es mir persönlich geht, weil ich das mit den “Schönheitsfhelern” so nicht stehen lassen kann:

Ideal wäre, wenn sich die Notification “einfach” in die System-Notification einklinken würden, so, wie es die meiste andere Software auch tut. Mittlerweile sind auch da Interaktionen möglich. Ich benutze seit ca. 15 Jahren Linux am Desktop. Erst KDE bis 3 (4 war die Katastrophe) dann Gnome 2 (die Gnome-Shell ist für mich unbenutzbar …) anschließend Cinnamon (was zunehmend genervt hat) und dann wieder KDE mit Pasma 5 (DIE Oberfläche, mehr Comfort und Konfigurierbarkeit geht nicht).

Das Problem ist, dass der Pascom-Client mehr oder weniger KDE-Agnostiker ist, besonders dann wenn man, wie ich, mit vielen virtuellen Desktops arbeitet. Der Knackpunkt dabei sind die Notifications. Nur wenn der Client im Vordergrund ist sind auch die Notifications direkt sichtbar. Ganz verborgen bleiben sie wenn man auf einem anderen virtuellen Desktop ist. Ist der Client in den Tray minimiert gibt es gar keine Notifications. Die Notifications werden erst dann sichtbar, wenn man den Client wieder auf seinem Desktop in den Vordergrund holt. Das alles macht die Notifications komplett nutzlos. Es geht hier also nicht um Schönheitsfehler.

Eine andere Usaliblity Unschönheit ist, dass man den Client nicht einfach durch Klick auf das Tray-Icon hoch holen kann, sondern immer erst rechte Maustaste und dann “Fenster anzeigen” klicken muss. Das ist nervig. Noch besser wäre, wenn der Client auf Desktop A offen ist und man auf Desktop C ist und das Icon im Tray klickt, dass dann der Client auf das aktive Desktop geholt werden würde. Das ist aber glaube ich nicht wirklich machbar. Klickt man im Moment auf “Fenster anzeigen”, dann wir man auf das Desktop geschickt auf dem der Client offen ist. Mein aktuelles Workaround ist den Client auf allen Desktops anzeigen zu lassen (mit KDE geht das) und ihn immer offen zu lassen und nicht in den Tray zu minimieren. So kann ich ihn mir wenigstens auf jedem Desktop nach vorne holen. Besser als nichts :slight_smile:

All das verdirbt einem den Spass an der Nutzung des Clients unter Linux bzw. besser gesagt KDE …

Hallo @jlorenz!

So, jetzt muss ich meinen Senf auch nochmal dazu geben. Ich würde hier nicht vom Format abweichen, denn genau das macht den Client derzeit so universell einsetzbar. Paketieren könnte man es im Bedarf selbst. Snap ist in der Linux Community nicht unbedingt heißgeliebt, da Ubuntu hier eine weitere Container-Lösung geschaffen hat, obwohl es Flatpack und andere gibt. Ich sehe es auch nicht in Eurer Verantwortung, Euch um eine Paketierung zu kümmern, denn genau dann kommt Ihr vom Hundertsten ins Tausendste und erzeugt neue Abhängigkeiten. Um es besser zu veranschaulichen, vielleicht ein Beispiel aus der Praxis. Ich habe in meinem letzten Post erwähnt, dass IGEL Thin Clients für uns recht wichtig sind. Obwohl es sich hier um keine klassische Linux Distribution handelt, sondern wir hier mehr von Read-Only Firmware reden können (die eben Ubuntu LTS als Basis nutzt), sind sogenannte “Custom Partitions” möglich, um Third Party Software implementieren zu können. Und das tun wir bei unseren Kunden, um den Split Client in Verbindung mit Terminal Services und Citrix nutzen zu können. Im Fall des pascom Clients sieht die Implementierung so aus, dass ich neben der erstmaligen Definition dieser Custom Partition lediglich das aktuelle .tar.gz Archiv herunterlade und die Versionsnummer in einer .ini Datei erhöhe, wodurch sich alle Thin Clients die aktuelle Version des pascom Clients laden. Einfacher geht es nicht. Snap würde hier definitiv weitere Komplexität einbringen (oder sogar unter Umständen eine Installation komplett unmöglich machen), ohne aber das eigentliche Problem, nämlich die Desktopintegration in die gängigsten Desktopoberflächen, zu lösen. Es geht hier meiner Meinung nach wirklich nur um die zwei großen, GNOME und KDE, von mir aus auch drei mit Cinnamon, und wie @mahescho es bereits erläutert hat, sind es Usability Thematiken, die einem im alltäglichen Betrieb unterkommen und schlecht durch automatisierte Testverfahren entdeckt werden. Die wirklich gute Unterstützung von Linux als Betriebssystem und damit die Verwendbarkeit auf Thin Clients ist meiner Meinung nach DAS Alleinstellungsmerkmal, das Euch vom Mitbewerb unterscheidet. Meiner Meinung nach würde es eben vollkommen reichen, Linux bei Euch selbst auf ein, zwei Arbeitsplätzen zu verwenden. Bessere Qualitätstests wird es wohl kaum geben. Ob das umsetzbar ist, kann ich natürlich nicht bewerten.

Liebe Grüße,
Daniel

3 Likes

@DHimler - ich bin ganz Deiner Meinung. TGZ reicht völlig und gerade für die IGELs ist das die einzig sinnvolle Lösung. Die Energie sollte besser in eine bessere Integration als in ein zweifelhaftes Paketformat gesteckt werden.

Ich sehe in snap auch nur Nachteile. Ich könnte den Client dann unter meinem Linux nicht mehr verwenden. Snap kommt mir nicht auf das System. Wenn ihr in die Richtung gehen wollt (was ich nicht nachvollziehen kann) dann AppImage oder Flatpack.

Der Distributionsweg für Linux in Form eines tgz ist einwandfrei. Die Integration in verschiedene Desktop Umgebungen könnte besser sein aber grundsätzlich bin ich hier sehr zufrieden.

Mein bescheidener Hinweis. Viele haben Ubuntu genau wegen Snap und dem daraus resultierenden Paket-Chaos (DEB, Snap, Flatpack) den Rücken gekehrt. Und auch ich bin deshalb zu LinuxMint

So würde ich es auch zusammenfassen.

Hallo @jlorenz

wann darf mit einem Paket zum testen gerechnet werden…

LG Maik

Hallo @maik,

kann ich noch nicht sagen. Ein erster Test verlief positiv. Im moment Arbeiten wir noch an der Build-Infrastruktur um vernünftig Beta-Versionen ausliefern zu können.

Grüße,
Jan

In der Hoffnung, dass es nicht das unsägliche Snap wird …

2 Likes