Stabilster Windowmanager / stabilstes Toolkit

Jeff

Well-Known Member
Hallo zusammen!

Seit August schreibe ich an einer Anwendung (unter NetBSD), die extrem ausfallsicher sein muß(sie wird selten mehr als 24 Stunden am Stück laufen, aber wenn sie läuft, darf nichts schief gehen, sonst sind die Folgen u.U. schlimm). Um möglichst vielen Risiken aus dem Weg zu gehen, war die Anwendung bislang komplett Text-/ Konsolenbasiert, damit eine Blockade durch Absturz des X-Systems/des Windowmanagers ausgeschlossen werden konnte.

Allerdings änderten sich die letzten Wochen meine Ideen ein wenig in Richtung langfristige Ausbaufähigkeit /Benutzbarkeit des Systems. Deshalb will ich die Anwendung jetzt doch mit einem X-basierten Userinterface bauen.

Die Frage ist nun: Welcher Windowmanager ist wirklich hart wie ein Fels? Die Optik ist völlig nebensächlich, wobei ich twm von der Bedienbarkeit nicht wirklich mag. fluxbox, von mir sonst alltäglich benutzt, ist für eine kritische Anwendung derzeit wohl noch nicht geeignet, da ich mindestens einen Absturz des Managers zu verzeichnen habe. Für KDE trifft das ebenfalls zu.
Was habt ihr für Erfahrungen gemacht? Welcher WM erscheint euch absolut stabil?

Außerdem bin ich noch auf der Suche nach dem passenden Window-Toolkit, welches ebenfalls sehr stabil sein sollte. Sympathisch ist mir fltk, die Programmierung mit GTK fand ich dagegen weniger übersichtlich, QT kommt wegen der Lizenz nicht in Frage. Mit fltk-Anwendungen habe ich mangels Masse an verfügbaren Programmen allerdings kaum Erfahrung.

Kurz: Was sind zu beiden Themen eure Erfahrung, oder Meinungen? Ich möchte eben erreichen, daß die größte Unsicherheit letztendlich meine eigene Anwendung ist ;-).
 
Zuletzt bearbeitet:
Programmier doch eine X-basierten Client für deine Applikation.
Da kann sie trotzdem weiterlaufen, wenn das X abstürzt.

Gruss...

Der Indy
 
Jeff schrieb:
Ich möchte eben erreichen, daß die größte Unsicherheit letztendlich meine eigene Anwendung ist ;-).

...das ist ein guter Ansatz :rolleyes:

Ich setze hier xfce4 ein und hatte auf meinem Notebook und auf dem Desktop in ueber zwei Jahren keinen Absturz, den der WM verursacht hat.

Aber ich kann mir auch vorstellen, dass das mit KDE/Gnome et al nicht anders aussehen wuerde!

Grundsaetzlich natuerlich: So schlank wie moeglich!
 
Wozu überhaupt ein WM?

Aber ich würd auch indy's Idee bevorzugen:
Einen Serverprozeß im Hintergrund, auf den dann ein Textmode- oder auch GUI/X-clientprogramm zugreifen kann.
 
@indy: Es wird ein Client sein. Ich werde in jedem Fall die Möglichkeit beibehalten, das Programm konsolenbasiert bedienen zu können. Allerdings ist eine schnelle, jederzeitige Reaktion des Benutzers auf Ereignisse sehr wichtig, woraus resultiert: Auch der Client muß sehr stabil sein. Bei einem Absturz des Clients/WM gibt es eine Rückfall-Ebene. Aber das Umschalten der Bedienung selber ist in bestimmten Betriebszuständen schlicht gefährlich.
Insgesamt könnte sogar ein Computerausfall über ein paar Minuten verkraftet werden (Neustart im Notfall), da die Anwendung ihre Zustände ständig speichert. Wie gesagt: Es gibt Momente im Betrieb, da wird das Krisenmanagement echt gefordert, daher muß alles von vorneherein sicher sein.
 
Also ich habe sehr gute Erfahrungen mit WindowMaker und ROX (auch im Verbund) gemacht (nutze auch NetBSD).

Sehr sehr schlank, sehr stabil und sogar sehr anwenderfreundlich ohne die Kiste gleich zuzumüllen à la GNOME/KDE.

Da ROX im Prinzip nur aus in Python geschriebenen FrontEnds zu Consolen-Befehlen besteht, sind die Anwendungen als quasi so stabil wie die Shell anzusehen. Es gibt auch eine lib für ROX, die wiederum auf GTK aufbaut.
 
@CAMISOLITE: ROX werde ich heute mal ausprobieren, hört sich ganz nett an.

Weiß denn noch jemand was über die Programmier-Toolkits? Neben fltk hat XForms noch ne passende (nicht übermächtige) Funktionalität, aber die Entwicklung wurde ja wohl noch vor Version 1.0 eingestellt.
 
Wenn Dir der WM abstürzt heißt das noch nicht, dass Dir ebenfalls X abstürzt. Die X-Anwendung ist unabhängig von dem WM. Wenn der WM abstürzt, dann hat die X-Anwendung den Fensterrahmen verloren und einige Features zum Fenster-Management. Na und? Notfalls kann man den WM noch ein Mal starten.

Wenn ein Toolkit Fehler hat oder der X-Server, bist Du natürlich aufgeschmissen.

Ich kenne aber ehrlich gesagt keine X-Anwendung, die "hochverfügbar" ist, in dem Sinne, dass sie immer laufen muss, um einen stabilen Betrieb zu gewährleisten. Dies ist immerhin nur die "Ansicht" und nicht die Funktionalität an sich. Das allein menschliche Augen nötig sind, um einen Job am leben zu halten, ist mir daher irgendwie nicht klar.

Deswegen wäre ein Trennung zwischen Funktionalität und Ansicht wünschenswert.
 
nakal schrieb:
Wenn Dir der WM abstürzt heißt das noch nicht, dass Dir ebenfalls X abstürzt. Die X-Anwendung ist unabhängig von dem WM. Wenn der WM abstürzt, dann hat die X-Anwendung den Fensterrahmen verloren und einige Features zum Fenster-Management. Na und? Notfalls kann man den WM noch ein Mal starten.
falls man keinen WM hat, der "absturzsicher" ist (Window Maker erkennt Abstürze und lässt sich dann wahlweise neu starten oder beenden), kann man sich damit abhelfen, in seine .xinitrc (oder vergleichbares) anstelle von
Code:
exec mein-window-manager
einfach so etwas einzubauen:
Code:
mein-window-manager
xmessage -buttons ja:0,nein:1 -default 0 -center -timeout 30 "Window Manager neu starten?"
if [ $? -eq 0 ];then
exec ~/.xinitrc
fi
(oder so ähnlich, ist schon länger her...)

auf bald
oenone
 
@moR-pH-euS:
stimmt, von xnee hatte ich auch gelesen. Wird mittelfristig wohl zum Einsatz kommen, da die Arbeit, wie zu vermuten, ziemlich exakt sein muß.
@nakal: Die Anwendung MUSS fehlertolerant sein, aber jedes Teil der letztlich laufenden Applikation aus Hardware/Software muß für sich so hart wie möglich sein um Irritationen zu vermeiden. Leider bin ich da etwas von Paranoia geplagt, aber aus guten Gründen.
 
Jeff schrieb:
@nakal: Die Anwendung MUSS fehlertolerant sein, ...

Ich würde sagen, dass das von der Anwendung und von der Situation abhängt. Ich arbeite mit High-Speed Druckern. Die Software muss sie die ganze Zeit beschäftigen, aber ich halte es jedenfalls für wenig sinnvoll 1 Million falsch beschriebene Blätter zu drucken, weil die Software fehlertollerant reagiert hat. Da ist mir ein geregelter Absturz (sog. "assertion") viel sauberer.

Ein Steuerungsprogramm kannst Du von der eigentlichen Anwendung immer trennen und das ist der einzig richtige/sinnvolle Weg. Die Kommunikation mit einem X-Server ist eine netzwerktechnische Sache. Überleg mal was bei einem Netzwerk alles schief gehen kann!

Es kann auch z.B. jeder Knilch kommen und Strg+Alt+Backspace drücken.
 
Zurück
Oben