X11/GUI/shell-based (Re: [linux-l] Gaaaanz Neue Distri)

[Jan Krüger]

Oliver Bandel wrote:
> Das ist kein Linux-Problem, es ist ein Problem des Auswählens
> von Geräten, die ganz speziell nur zu einem SW-Hersteller hin
> ausgelegt sind und GARNICHT PASSEN SOLLEN.
> 
> Wenn man sich einen vernünftigen Drucker aussucht,

Also wenn ich zum Media-Markt gehe und sage "Drucker, Linux" sagt der 
Verkäufer "geh weg, du bist mir egal"

Oder anders ausgedrückt: Welche Wahl?

> einen, der nicht speziel proprietär Windows-spezifisch ist
> und auch nur closed specifications unterstützt, dann
> ist es selbstverständlich kein Problem.
> 
> Deine Argumentation hinkt ganz einfach, weil sie darauf
> hin ab zielt, daß Linux nicht gut genug/weit genug sei,

Richtig, weil es eben noch nicht geschafft hat für Freiheit bei der 
Auswahl von Komponenten zu sorgen.

> und es deswegen Murks sei.

Genau. IST (für einige Einsatzbereiche)
oder auch nicht (für andere Einsatzbereiche)

> Dabei liegt das problem doch
> dort, wo keine Spezifikationen frei gegeben werden.
> Das kann ebenso bei anderen kommerziellen Betriebssystemen
> auftauchen und ist kein Linux-Spezifikum, sondern
> ein Politikum.

Jupp. Und dieses trifft Linux (und *BSD usw.). Also auch ein 
Linux-Problem ;)

>>Wie Jan-Benedict es schon gesagt hat in einem anderen Zusammenhang:
>>"[...] wie ls, cp, mv, rm, ..."
>>
>>Also kleine, feine Komponenten die man per bash, python oder
>>(was auch immer)TM (beinahe alle Scriptsprachen beherrschen irgend ein 
>>exec oder system oder so) zusammen scripten kann. Daraus resultiert, 
>>daß Anwendungen keine kompilierten Programme sind, sondern scripte, 
>>welche die kompilierten "Programme", Komponenten genannt, 
>>zusammenfügt. Halt den Unix Gedanken konsequent weiter geführt und 
>>umgesetzt.
> 
> 
> Kann auch compiliertes sein, was da eingesetzt wird.
> ls, cp, ...  sind ja auch keine bash-scripte.

Ja, das währen ja die Komponenten. Die Anwendung währe das 
bash-script, welches durch zusammanfügen von ls, cp, rm ... zb. /tmp 
aufräumt oder ein Backup macht.


> Wie das dann mit der GUI aus Einzescripten her aussehen soll,
> hmhh, da habe ich nur eine vage Vorstelung von.

Ich auch eine eher sehr verschwommene ;), ist mir halt bisher so noch 
nicht begegnet.
oeone.com (Mozilla/XUL) und XAML kommen dem nahe, halt von der anderen 
Seite her (RIESEN-Framework fast durch und durch scriptbar mit XML)

> Aber Tcl/Tk ist ja letztlich auch nur eine Applikation, und
> so in der Art meinst Du es sicherlich nicht.
> (Tcl hat eh 'ne Kack-Syntax).
> 
> 
> So weit ich weiss, gibt es aber nicht nur ein C-Interface zu X, sondern
> auch ein scheme-Interface zu X.
> Damit könnte man bestimmt ganz gute Sachen machen... :)
> Ist mir aber nicht bekannt, ob das überhaupt bei den normalen
> Linux-Distris mit dabei ist, oder ob das alles irgendwo auf
> einem Server vergammelt.
> 
> Aber möglicherweise meinst Du ja, man solle auch auf X verzichten?
Nö, bloß nicht. X ist schon eine gute Sache.

> Oder sollen diese modularen GUI-Komponenten schon auf X aufsetzen?
Jaja, X bringt ja die Einbettungsfähigkeit durch das Box in Box 
konzept mit.

> Naja, man könnte sich schon cortsellen, daß man ne GUI-shell
> hat, die man dann entsprechend nutzt, oder so.
> Oder Einzeltools für GUI-Paramater-Einstellung.
> 
> Statt bash dann Xash oder so? Oder Xguish?
Ist ja egal, weil es eh executable scripte sind aus (was auch immer)TM 
die dann die komponenten aus denen die GUI und Anwendungen geformt 
werden aufrufen.

Gruß
Jan