Hört sich auf jeden Fall nicht schlecht an. Nur frag ich mich, ob sich das System (abgesehen davon, wie gut es ist) überhaupt durchsetzt, es gibt schon jetzt ziemlich viele "Alternativen" zu X. Son Standart, den mal so viele Leute, wie X benutzen sollen, sollte vielleicht nicht von einem Einzelnen geplant werden...
Ich finde den Namen gut. Ist konsequent (W -> X -> Y) und man weiß, daß es der Nachfolger von X ist. Außerdem bleibt damit der Wortwitz von X erhalten. (:
Ich glaube auch, dass X ein so zentraler Teil eines Standard Unix/Linux System ist, dass alle inkompatiblen Alternativen auf absehbare Zeit Totgeburten oder Nischenprojekte sind.
Wer soll denn die Milliarden Zeilen Code auf das neue grafische System portieren?
Selbst wenn sich Y/BerliOS/... wirklich jemals verbreiten würden, hätten wir dann wohl für Jahre alle zwei grafische Systeme installiert, mit eigenen Konfigurationen, Inkompatibiltäten, ... und darauf freue ich mich wirklich nicht.
Ich glaube der einzig vernünftige Weg, der allem Anschein nach auch eingeschlagen wird, ist X (in einem neuen, fexibleren Entwicklungsmodell) weiterzuentwickeln.
Das Problem beim Y-Window-System ist, daß es unter der GPL steht. Es wird zwar schon diskutiert, es unter die LGPL zu stellen, doch XFree ist - zumindest mit seiner alten Lizenz v. 1.0 - viel liberaler. Vor allem den BSDs dürte somit die GPL/LGPL-Lizenz wohl wenig gefallen.
>Vor allem den BSDs dürte somit die GPL/LGPL-Lizenz wohl wenig gefallen.
Warum?? Mit der LGPL gibt es da überhaupt keine Probleme! Du darfst es gegen alles linken nur das LGPL Programm selber muß frei sein und das finde ich auch gut, man muß ja nicht alles an die Industrie verscherbeln die dann einen haufen Kohle damit machen und nie etwas zurüxk kommt.
Selbst mit der GPL sollten die BSD Leute keine Probleme haben da ihre Lizenz GPL Kompatibel ist...
Es reicht ja wenn die BSD Lizenz GPL Kompatibel ist. D.h. mann kan BSD Lizensierten code in GPL lizensierten einbauen, man kann BSD Programme gegen GPL libs linken,...
Wenn ich BSD code und GPL code zusammeführe ist es ganz einfach. Solange es zusammen ist überwiegt die "restriktivere" Lizenz, d.h. ich darf das gesammte nach den Richtlinien der GPL verwenden. Ich kann natürlich jederzeit den BSD Teil rausnehmen und damit dann alles machen was mir die BSD Lizenz erlaubt.
Von Lord Zwiebel am Fr, 20. Februar 2004 um 17:48 #
Zeigen sich hier wieder einmal eindeutig die drastischen Schwächen der GPL? Vergesst die GPL und gebt der LGPL den Vorzug - das sollte uns allen das Beispiel KDE gezeigt haben. Gnome (der objektiv betrachtet weniger weit entwickelte Desktop) erhält den Vorzug nur weil dessen Libs auch für Kommerzielle Dinge verwendet werden können. Dass mit der Lizenz von Qt keine Möglichkeit für ein KDE unter LGPL bestand rächt sich spätenstens jetzt...
Und nochwas: wenn man das Grafische System neu zusammenschrauben will: gehe man doch den OS X-Weg - etwas Besseres wird man schwer finden können...
Von Lord Zwiebel am Fr, 20. Februar 2004 um 18:47 #
Danke für diese direkten Komplimente. Aber worum es hier geht ist nicht Gnome - sondern nur dessen Libs - GTK also - und diese stehen unter LGPL - was das Verwenden in kommerziellen Anwendungen ohne Weiteres möglich macht - deshalb der Einsatz auf Suns Java-Desktop und bei Userlinux
Dagegen: KDE (dessen Libs) basiert auf QT - das unter der GPL steht - womit kommerzielle anwendugen nicht möglich sind, ohne den Quellcode zu veröffentlichen (das wird nicht jeder hinnehmen) - alternativ kann man sich die QT-Libs ja auch lizenzieren (mit Geld) - und weil Geiz heutzutage Geil ist, nehmen viele lieber GTK. War das jetzt wirklich so schwer zu verstehen? > (*unbeguerndete_behauptungen*)
Was Du hiermit zu sagen versuchst, ist mir nicht ganz klar. Nichts für ungut.
>Aber worum es hier geht ist nicht Gnome - sondern nur dessen Libs - GTK also - und diese stehen unter LGPL - was das Verwenden in kommerziellen Anwendungen ohne Weiteres möglich macht
Auch QT libs, oder libs allgemein unter der GPL koennen in kommerziellen Anwendungen verwendet werden!
>War das jetzt wirklich so schwer zu verstehen?
Du hast vorher nicht von den libs gesprochen sondern das hier geschrieben: "Dass mit der Lizenz von Qt keine Möglichkeit für ein KDE unter LGPL bestand rächt sich spätenstens jetzt..." und das ist einfach falsch! Da man KDE unter die LGPL haette stellen koennen!
>> (*unbeguerndete_behauptungen*) >Was Du hiermit zu sagen versuchst, ist mir nicht ganz klar.
ich halte es fuer eine unbegruendetet und unhaltbare Behauptung das gnome der "weniger weit entwickelte Desktop" ist. Dir gefaellt KDE oder dessen Entwicklungsrichtung besser? OK, aber weil dir KDE besser gefaellt muss gnome nicht schlechter sein.
Ausserdem halte ich von beiden (Suns Java-Desktop und Userlinux) nicht viel. Und mir gefallen die QT libs besser wie die GTK libs, nicht weil sie vielleicht technisch besser sind (was ich auch garnicht glaube) sondern wegen der Lizenz. Ich finde die Lizenzpolitik von QT super und sie gibt uns in der free Software community dadurch auch einen gewissen Vorteil und schuetzt uns vor crippleware wie z.B. Leute die meinen nur weil GNU/Linux etwas bekannter wird ploetzlich dafuer shareware oder freeware zu entwickeln...
Nicht ganz, sie sind neben der GPL noch unter der QPL (oder so ähnlich) lizensiert. Die QPL ist der LGPL ziemlich ähnlich, erlaubt aber keine proprietären Programme sondern nur Programme unter einer anderen freien Lizenz (z.B. modifizierte BSD Lizenz, (alte) X11, MIT Lizenz,...)
>Ich denke, dass er sich dessen bewusst ist. >Solche Behauptungen werden praktisch immer absichtlich verbreitet.
Du hast meine Antwort darauf gelesen? Nein! Sonst würdest du nicht so einen sch*** erzählen, dass ich absichtlich falsche Informationen streuen würde...
Es ist vielleicht besser wenn man erstmal einen Thread ließt bevor man meint seinen Senf dazugeben zu müssen!
Tut mir leid, aber Lord Zwiebel hat recht. QT steht nur unter der GPL, während GTK unter der LGPL steht.
Damit fällt die Entwicklung geschlossener, kommerzieller Applikationen für QT flach, sofern man nicht auf die QPL (so hieß sie glaube ich) zurückgreift. Für die verlangt Trolltech natürlich Geld (wie Lord Zwiebel schon schrieb).
PS: "Besser als", nicht "besser wie". (: PPS: "lizenzieren", nicht "lizensieren". <:
und der QPL, welche dir erlaubt auch gegen andere freie Lizenzen zu linken. Damit kann man z.B. auch Programme unter der BSD, MIT, X11,... lizenz entwickeln!
>Damit fällt die Entwicklung geschlossener, kommerzieller Applikationen für QT flach
Die Entwicklung proprietärer Software fällt flach! Kommerzielle kann man damit ohne Probleme entwickeln! Und warum sollte jemand der die Rechte des users bei seiner eigenen Entwicklung nicht berücksichtigt verlangen können das seine eigenen vom Toolkit Hersteller berücksichtigt werden? Ich finde die Lizenzen Politik von Trolltche super!
>sofern man nicht auf die QPL (so hieß sie glaube ich) zurückgreift.
du meinst die "Qt Commercial License", die QPL ist eine freie Lizenz
> und weil Geiz heutzutage Geil ist, nehmen viele lieber GTK. Mag schon sein, dass Firmen Geld sparen wollen aber so ein paar QT-Lizenzen kosten doch verhältnismäßig wenig...
Von Meinereiner am Fr, 20. Februar 2004 um 16:23 #
Tja, nur da ist das Problem das die aktuellste X-Version einen dämlichen Zusatz in der Lizenz hat daß bisher alle Distributionen abgelehnt haben den aktuellen X in ihr System mit aufzunehmen.
Bestimmt so ein Framebuffer basiertes System das dann maximal in VGA-Auflösung funktioniert. Mal was neues ist ja nicht schlecht, aber woher sollen die ganzen Treiber kommen? Geschweige das Hardware auch 3D-accelerated unterstützt wird. Daran haben sich schon andere die Zähne ausgebissen und sind gescheitert. So eine Geschichte wie der Xserver von Freedesktop.org hat da eher Chancen, weil er auf die xlib aufsetzt und damit auch alle Anwendungen von KDE bis Gnome ohne Probleme sofort laufen. Allerdings besteht hier natürlich auch das Treiberproblem - eigentlich das einzige Problem was immer vorhanden ist und neue Konzepte fast unmöglich macht.
>Allerdings besteht hier natürlich auch das Treiberproblem
Das halte ich für kein (großes) Problem. Eigentlich laufen so gut wie alle Grafikkarten mit freien Treibern und auch 3D geht wenn man sich die richtige Grafikkarte aussucht. Z.B. gibt es afaik für ATI und Matrox Karten freie Treiber die 3D-beschleunigung unterstützen.
Das ist nur ein Problem wenn man sich von Firmen wie nvidia abhängig macht und irgendwann sogar anfängt zu glaube das diese Abhängigkeit die einzige Lösung ist.
Aber dann hätte man in den Anfangstagen von GNU/Linux auch argumentieren können das es nie eine chance hat, da es kaum brauchbare Programme dafür gab...
>Das halte ich für kein (großes) Problem. Eigentlich laufen so gut wie alle Grafikkarten mit freien Treibern und auch 3D geht wenn man sich die richtige Grafikkarte aussucht.
ich denke es wäre dennoch umfangreich die Treiber von X nach Y zu portieren. Dann noch die ganzen Fehlerchen die sich einschleichen, ist ja nicht gleich alles stable. Cooler wärs würde Y gleich die X-Treiber schlucken
Kein grosses Problem? Das sind zig Chipsätze und die Treiber sind alle auf das XFree-Modell ausgerichtet. Der müsste jeden Treiber erstmal in die Hand nehmen, verstehen wie er funktioniert und dann die entscheidenden Routinen herausnehmen um dann seine angepassten Treiber zu schreiben... Ausserdem ist der Typ nicht Keith Packard oder hat sonstwie Erfahrung mit solchen Systemen. Der fängt quasi bei Null an und muss selbst noch viel lernen...
Um sowas durchzuziehen müssten alle Xfree-Experten dort mithelfen. Wenn Packard und andere sich dem Projekt anschliessen würden dann könnte es was werden.
> ist X11 allerdings am Ende seiner Reise anbelangt. Das System sei seiner > Meinung nach zu inflexibel, langsam, verfügt über kein Standard-Toolkit und > macht den Programmierern viel zu viel Arbeit. Thomas sei fest davon > überzeugt, dass die Zeit gekommen ist, das altgediente X durch ein modernes > System zu ersetzen.
Also meiner Meinung nach, wird es wohl nichts.
Es stimmt schon, daß ein Standard-Toolkit von Vorteil ist. Jedoch ist dafür das Betriebssystem Linux (genauso wie FreeBSD, OpenBSD, etc) nicht für geschaffen.
Die Idee hinter Linux ist die Auswahl zu haben. Indem das Toolkit vorgeschrieben wird, fällt diese Auswahl weg. Und sofern überhaupt etwas eng mit Linux verbunden ist, so wäre es höchstens die grafische Oberfläche. Wenn man die nun ducrh etwas anderes austaucht, dann ist fast schon wie ein neues Betriebssystem.
Ich mein, es wurde ja auch schon die grafische Oberfläche von AtheOS (inzwischen Syllable genannt) auf Linux portiert und Cosmoe genannt. Trotzdem ist Syllable wohl - sofern man von Populatität reden kann - um einiges populärer und "verbreiteter" als Cosmoe.
Es gibt viele Betriebssysteme, bei denen nun die grafische Oberfläche direkt auf dem Kernel aufsetzt. Dort sind dann auch die meisten Kommandozeilenprogramme meist direkt als GUI-Programme vertreten. Es gibt Betriebssysteme bei denen somit der Kernel, die grafische Oberfläche und die Widgets eins sind. Noch dazu mit einer Startleiste. Als Beispiele wären hier Windows und BeOS zu nennen, die es in Zukunft wohl auch als ReactOS und OpenBeOS als OpenSource gibt. (Wobei Spiegel.de heute sogar über ReactOS berichtet hat).
Der Vorteil dieser Verschmelzungen ist, daß man dadrauf zugreifen kann. Ein Programmierer weiß, daß unter Windows die Windows-Startleiste zur Verfügung steht und man dort sein Icon integrieren kann. Das selbe gilt für BeOS. Aber bei Linux kann es sein, daß das KDE-Panel dort ist, daß das GNOME-Panel dort ist oder jemand erst garkein Panel auf seinem Desktop hat.
Somit müßte man auch ein Panel direkt mit ins Y-Windows integrieren.
Dieses würde jedoch direkt wieder als Konkurrenz zum KDE und GNOME-Panel stehen.
Desweiteren werden wohl noch immer viele Personen, auf manchen Rechnern erst garkein X oder Y draufhaben.
Anders ist es bei BeOS und Windows. BeOS kann man nicht im CLI-Modus starten. Terminalbefehle wie "alert", die man in ein Shell-Skript integrieren kann, öffnen grundsätzlich ein Fenster. Und jeder Entwickler weiß, daß wenn er ein Shell-Skript schreibt, das aler aufruft, daß alert auch zur Verfügung steht.
Ein ähnliches Programm scheint es von Sun auch für den GNOME2-Desktop zu geben. Aber Linux-Entwickler werden es wohl kaum nutzen, denn es könnte auch sein, daß GNOME nicht installiert ist.
Insofern sehe ich schon einen Vorteil eines einheitlichen Desktops. Aber Y geht wohl zum einen nicht weit genug, zum anderen ist es die falsche Zielgruppe. Besser wäre es komplett einheitliches System, das neu entwickelt wurde.
Von fragekostetnichts am Fr, 20. Februar 2004 um 14:56 #
"Es gibt Betriebssysteme bei denen somit der Kernel, die grafische Oberfläche und die Widgets eins sind. Noch dazu mit einer Startleiste. Als Beispiele wären hier Windows und BeOS zu nennen, die es in Zukunft wohl auch als ReactOS und OpenBeOS als OpenSource gibt. (Wobei Spiegel.de heute sogar über ReactOS berichtet hat)."
Woher willst Du wissen, dass unter Windows, Kernel, GUI und Widget eins sind? Das glaube ich eher nicht. Lasse mich aber gerne belehren. Windows kommt ja im Gegensatz zu Linux nicht aus einer monolithischen Kernelkultur.
Von fragekostetnichts am Fr, 20. Februar 2004 um 15:07 #
Fand gerade folgende Seite:
http://c2.com/cgi/wiki?MicroKernel
"Mach, WindowsNtKernel?, GnuHurd and DarwinOs (kernel of MacOsx) are examples of MicroKernel. -- TakuyaMurata ...
WindowsNtKernel? is also not actually a microkernel, although it was marketed as a microkernel when microkernels were fashionable. For example, the NT executive (aka the kernel) is implemented above a hardware abstraction layer. In a true microkernel OS, the kernel itself is the hardware abstraction layer. And now, since the graphics and GUI components have been moved into kernel space, NT is even less of a microkernel OS."
Damit habe ich gemeint, daß alles automatisch bei der Installation des Systems mit drauf ist. Natürlich ist das nicht alles eine Datei. Und natürlich kann man es auch austauchen. Aber es gehört nun mal alles mit zum System (zumindest bei Windows NT und Nachfolger, denn bei Win95/Win98 kann man auch den DOS-Modus starten, dann hat man soetwas wie Linux ohne X oder Y).
Somit startet Windows NT, Win2k, WinXP, etc gegenüber Linux direkt im grafischen. Und etwas anderes ist auch nicht möglich (bei BeOS genauso).
Und auch die Startleiste (die, wo wenn man aus "Start" klickt, direkt dadrüber etwas hat, wo "Beenden" steht) ist auch ein Teil des installierten Systems (ähnliches gibt es auch bei BeOS). Und unten rechts neben der Uhrzeit können dann Applikationen die gerade laufen (wie Outlook, Soundsteuerung und so) sich als kleine Icons verewigen. (ähnliches gibt es auch bei BeOS) Bei Linux ist es jedoch in der Form nicht so leicht möglich. Dann müßte der Entwickler festlegen, daß bei einem GNOME1-Panel das Icon im GNOME1-Panel sitzt, bei einem GNOME2-Panel im GNOME2-Panel beim KDE3-Panel im KDE3-Panel und bei den anderen KDE versionen ebenso. Und man müßte berücksichtigen, was passiert, wenn kein Panel vorhanden ist.
Einer der netten Features bei einem Panel das zum System gehört, sieht man bei Windows beim Programm Outlook (man kann von Outlook halten, was man will, aber dieses Feature ist gut): Wenn bei Outlook Mail reinkommt, dann erscheint unten rechts auf der Startleiste ein kleier Briefumschlag. Sehr nützlich, wenn man gerade andere Programme auf hat. Ähnliches gibt es auch bei Netscape, doch ist es dort nur auf das Netscape-Fenster beschränkt. Das heißt, wenn ich gerade im Internet surfe, sehe ich bei Netscape unten im Fenster, daß Mail gekommen ist. Wenn ich jedoch stattdessen ein anderes Programm gerade offen habe und Netscape minimiert wurde, dann sehe ich nicht mehr, wenn Mail reinkommt.
Von dirk.loesche am Fr, 20. Februar 2004 um 15:48 #
Also um nachzuschauen ob ich Post hab nehm ich korn. Und das hab ich so eingerichtet das "Sie haben Post in ihrem Online Postfache.wav" abgespielt wird bei neuer Post. Die Startleiste von KDE hab ich ausgeblendet. Und würde irgendeinblinken von irgendwas auch garnicht sehen. Geht das bei Outlok auch? Das man das konfigurieren kann? Und läuft Outlock dann die ganze Zeit im Hintergrund?
Wieso muss man dafür das Window System überarbeiten? KDE und Gnome sind nichts anderes als Fenstermanager die diese lustigen Features ebenfalls integrieren können.
Ob nun ein Symbol in der Kontrollleiste erscheint hängt immernoch vom Fenstermanager ab, und das soll auch so bleiben.
Das was du meinst sind wohl eher Bibliotheken die eine Schnittstelle für Nicht-KDE oder Nicht-Gnome Programme Funktionalitäten von KDE / GNome ermöglichen. Die Realisierung hängt aber vom Fenstermanager ab und KDE hat sowas schon integriert (kio-plugins).
Von Outlook ist nicht alleine - un am Fr, 20. Februar 2004 um 23:25 #
... auch bei Mozilla Thunderbird gibts einen kleinen Briefumschlag :)
was die Installation von Programmen angeht: Dann müsste man endlich wegkommen von der Praxis, dass die Programme sagen, wohin sie sich installieren wollen (läuft ja eh schon bei Windoof schief), und hin zu einer standartisierten Struktur (Verzeichnisse, Files, etc.), damit danach GNOME, KDE und Co. die Programme zuerst in die Programmliste und der Anwender danach diese in das Dock/Kontrollleiste/whatever aufnehmen kann.
> Gemeint waren Toolkits, also motif, qt, gtk, wxwindows, tk, swing (um nur die bekanntesten von dennen zu nennen).
Diese Auswahl hat man auch bei Windows. Der große Vorteil unter Windows ist, dass die Anwendungen für den Anwender gleich aussehen, egal ob MFC, Qt, Swing oder sonstwas verwendet wurde. Und so sollte es auch sein. Was interessiert es den Anwender, in welcher Programmiersprache und mit welchem Toolkit der Entwickler hantiert?
Von nochmal ??? am Sa, 21. Februar 2004 um 14:52 #
Sie sehen nicht alle gleich aus. Das ist ein Trugschluss.
Aber zumindest wird man weitgehend mit Totalschrott verschont. Athena-Widgets, TK, Motif oder Motif-Clones z.B. gehören entsorgt. Aber man muss sich unter Linux immer noch damit rumquälen. Z.B. bei Adobe A-Reader. Oder X-Emacs. Ein erbärmlicheres GUI kann sich für die eierlegende Wollmilchsau doch gar nicht finden lassen.
Von Fredolowkoskaia am Sa, 21. Februar 2004 um 22:47 #
Der Vorteil dieser Verschmelzungen ist, daß man dadrauf zugreifen kann. Ein Programmierer weiß, daß unter Windows die Windows-Startleiste zur Verfügung steht und man dort sein Icon integrieren kann. Das selbe gilt für BeOS. Aber bei Linux kann es sein, daß das KDE-Panel dort ist, daß das GNOME-Panel dort ist oder jemand erst garkein Panel auf seinem Desktop hat.
Was durch das Debian-Menu-System schon lange überhaupt gar kein Problem mehr darstellt.
Ist ein Problem. Das Menü ist ja nur ein kleiner Punkt. anderes Beispiel: Mozilla/Firefox-Download-Manager. Show File location. Was machen unter Linux? Einfach den Punkt aus lauter Hilflosigkeit deaktivieren. Unter Windows poppt der Explorer auf. Zahlreiche weitere Bsp. lassen sich finden.
Die alte Tradition, XWindow als Xwindows zu bezeichnen (zuviel MS-Werbe-Input?) lebt weiter. Die Domain lautet y-windows.org, obwohl dort nur von Y-Window die Rede ist. Naja, y-window.org ist ja auch noch frei...
Normalerweise geht bei X jede Graphikdirektive über Loopback-Sockets oder Netzwerksockets. Y möchte standardmässig eine schnelle Nicht-Socket-Kommunikation verwenden und nur im Falle eines auf einen anderen Computer exportierten Displays den Weg über ein langsames Socket gehen. Bravo.
"Various levels of access. Different languages and different environments provide different communication primitives. High level object-based languages might best interface with Y at the object level, utilising their own object communication system. At a lower level, systems that provide fast message passing should be able to use this as their primary communications primitive. Finally, it should be possible to communicate with the server using socket connections, as this is the level at which network transparent applications will be able to communicate with the server."
Ich kann es dir leider auch nicht genau sagen, aber X benutzt keinesfalls so eine art DISPLAY=127.0.0.1:0, falls du das *so* meintest. Lokal benutzt X jedenfalls etwas anderes als über netzwerk.
Ganz genau, lokal verwendet X11 Shared Memory für die Interprozesskommunikation und diese Methode ist *sehr* schnell. Die Geschwindigkeit hängt im Endeffekt natürlich davon ab wie X11 mit dem shm umgeht, aber an sich ist es die schnellste Methode überhaupt.
X11 ist meiner Meinung nach überhaupt nicht "langsam" (wobei Geschwindigkeit die Menge an Grafikprimitiven pro Zeiteinheit ist, die ein Client lokal zeichnen kann). Das was der Benutzer als langsam empfindet kommt meißt durch ganz andere Sachen. z.b. die Toolkits (kdelibs z.b. die qt ja noch um einiges aufblähen), die enorme anzahl an Libraries die manche Programme benutzen und teilweise auch die uneffiziente Programmierung von Toolkits (was zugegeben durch die Xlib auch ziemlich kompliziert ist)
Y-Windows ist natürlich auch ein geniales Wortspiel. Da ist es nur eine Frage der Zeit, bis unsere Freunde aus Redmond mit Y-Linux? (tm) an den Start gehen...
Hmm, diese Trollerei in der Spezifikation von Y-Windows gegenüber C++ verstehe ich nicht. C++ ist perfekt dafür geeignet. Meiner Erfahrung nach sollte man besser nichts mehr heutzutage in C anfangen. Die Gründe die er gegen C++ aufführt sind eher mau und wissenschaftlich korrekt ist die ganze Arbeit auch nicht. Der Abschnitt ala "C++ ist scheisse (siehe Stroustup et al)" ist doch lachhaft. Der sollte lieber noch ein paar Kurse belegen...
Von Hänsel und Gretel am Fr, 20. Februar 2004 um 16:16 #
Welche Trollerei? Dein Beitrag? Die Gründe, die er gegen C++ aufführt sind keineswegs mau. Vielleicht findest du sie irrelevant aber andere Leute sehen das eben anders und das auch zurecht. Ich persönlich finde viele Scachen an C++ auch zu kotzen. Es ist zwar nicht übel, aber perfeckt ist es keineswegs...
Von El Pseudonymo am Sa, 21. Februar 2004 um 10:26 #
Welche Trollerei?
Zum Beispiel auf Seite 15 des Reports:
"[...] pointers to members cannot be subsumed under the type of ther receiver [...], that is a member pointer '&Canvas::drawLine' which is of type 'void Canvas::* (...)' cannot be safely converted to a pointer of type 'void Object::* (...)' even though 'Canvas' inherits from 'Object'. "
Nun, dafür gibt es gute Gründe. Wenn er das als Grund nimmt, nicht C++ zu verwenden könnte, man das als Trollerei bezeichnen, denn egal welche Programmiersprache er nimmt, diese Einschränkung müßte er eigentlich in jeder nachbauen.
Also ich sehe das etwas anders. Die Einschränkung der nicht sauber möglichen Rückkonvertierung ist eine direkte Folge des Objektmodells von C++.
OO-Sprachen die auf Nachrichtenebene arbeiten und echte dynamische/späte Bindung beherrschen (also nicht die Krüppellösung die man unter C++ als late binding bezeichnet) haben dieses Problem meistens nicht. IPC/RPC mit Objekten unbekannten dynamsichen Typs lässt sich zwar bei C++ auch per RTTI und änliche Geschichten hinbastelt, was aber aufgrund der psuedodynamsichen Bindung, die direkt auf ebene der Funktionsaufrufe realisiert ist, nicht gerade schön zu realisieren ist. Erschwerend wird es, wenn die Zielobjekte und deren Kommunikationsschnittstellen zur Übersetzungszeit völlig unbekannt sind und deshalb keinerlei Prototypisierung möglich ist um den dynamischen Datentyp zu erlangen. Auch ist eine dynamsiche Vererbung zur Laufzeit im C++ Objektmodell nicht realisierbar. Viele Bibliotheken, die unter C++ IPC, RPC und Signalbehandlung bereitstellen hüpfen generell zwischendurch immer wieder aus dem Objektmodell von C++ heraus, da vieles ansonsten garnicht erst realisierbar wäre.
Sicherlich, man kann alles mehr oder weniger sauber auch mit C++ machen. Aber wieviel bleibt mir dann noch von C++ übrig, wenn ich sowieso überall irgentwelche dreckigen Hacks reinbasteln muss. Hier geht es ja auch nur um den Kern. In welcher Sprache die Module geschrieben werden ist dank C auch ziemlich egal. Mit C++ müsste man hier auch wieder die ABI mit ner C Bindung aussatten oder man baut wieder irgentwelche dreckigen Sachen ein um die C++ Namesauflösung zu umgehen und um das C++ Objektmodell zu verstecken.
Für Y ist es nur wichtig einen möglichst kleinen, flexiblen und sauberen Kern zu haben um den sich dann die Module rumtümmeln. Und ob C++ dafür wirklich so sinnvoll ist bezweifle ich bezüglich der gegebenen Probleme sehr.
Von El Pseudonymo am Sa, 21. Februar 2004 um 13:06 #
Also ich sehe das etwas anders. Die Einschränkung der nicht sauber möglichen Rückkonvertierung ist eine direkte Folge des Objektmodells von C++.
Nein, das glaube ich nicht. Wenn man einen Zeigertyp auf eine Methode einer abgeleiteten Klasse hat, dann kann man durch diesen Typ immer Methoden aufrufen die in einer Basisklasse nicht vorkommen. Das ist ein ziemlich universeller Sachverhalt der bei weitem nicht auf C++ beschränkt ist. Man muß sich auch bei anderen Sprachen in vergleichbaren Fällen erst versichern das das Objekt für das die Methode gerufen wird den passenden Typ hat.
Das Problem betrifft natürlich auch einige andere Sprachen. Es ist aber nur bei Sprachen vorhanden, die eine funktionsbassierende Methodenbeding nutzen (wie eben C++). Bei Nachrichtenbasierter Methodenbindung ist das ganze in der Regel egal. In einigen Sprachen kann ich Nachrichten an ein Objekt schicken wie ich lustig bin. Der Typ des Objektes ist dabei völlig irrelevant. Versteht das Objekt diese Nachricht wird sie abgearbeitet, versteht es sie nicht wird ne Fehlermeldung zurückgeliefert. Dazu ist natürlich ein RTE nötig, das diese Sachen behandelt.
Und genau das passiert bei Y. Die eigene Objektsystem ist in diesem Falle das RTE für die IPC/RPC und die Module. Das Ganze auf C++ aufzusetzen, wäre als wenn ich nem Schwein mit Flügeln ein zweites Paar Flügel dranbasteln und das erste Paar mit Heftklammern im A... befestige.
Von El Pseodonymo am Sa, 21. Februar 2004 um 14:11 #
Naja, so wie du das jetzt erklärst, könnte ich dir schon eher zustimmen.
Aber besonders stichhaltig finde ich das trotzdem nicht. C++ hat über C ja noch mehr zu bieten als nur OOP im besprochenen Sinn.
Außerdem kann ein Nachrichtenbasiertes RTE ja durchaus mit den OOP Features die C++ hat koexistieren. Dann hätten in C++ geschrieben Anwendungen immer noch den Vorteil dieses RTE eventuell nicht benutzen zu müssen, während es, sollte es nötig sein, bereitsteht.
Ich perönlich zweifel auch daran, das eine solche "Full-Blown" Middleware noch einmal extra für ein Graphisches Desktop System Sinn macht. Es gibt ja schon so viele. Aber das ist natürlich (genauso wie die Wahl der Sprache) Sache von den Entwicklern.
Durchdas Y eine möglichst hohe Modularität als Ziel hat dürte die Wahl der Sprache für den eigentlichen Kern sowieso nur ein paar Hansel interresieren. Die Anwendungsenwickler kriegen davon überhaupt nichts mit, da die Clientlibs das ganze höchstens tangiert, aber keine direkte auswirkungen auf sie hat. Und die Leute, die Module schreiben sehen nur eine C schnittstelle, die sich z.B. für C++ Module auch noch mit nem Modultemplate so verzieren lassen dürfte, dass sich C++ Programmierer auch heimisch fühlen.
Was die nicht OOP Erweiterungen von C++ angeht so muss man in dem Fall natürlich mit einbeziehen, dass man diese Teilweise auch über C99 nutzen könnte (was aber bei einigen Compilern zu kleinen Problemen führen könnte) und das man dann dennoch versuchen müsste eine möglichst Sprachunabhängige Modulschnittstelle zu bekommen, was bei C++ durchs name mangling nicht gerade sehr einfach ist.
C++ war auch nie als eierlegende Wollmilchsau konzipiert. Es gibt genug Möglichkeiten das was fehlt anders hinzubekommen. Das mit den dynamischen Typen funktioniert sehr gut zur Laufzeit wenn man sich auf eine Zwischensprache zur Beschreibung der Schnittstellen und Typen festlegt. IDL mit COM sei nur mal ein Beispiel.
Alles eine Sache des Designs. Abstrakte Basisklassen sind z.B. kein dirty Hack zum umgehen der Namensauflösung sondern sogar aus OO-Sicht eine sehr saubere Lösung. Die meisten sind einfach mit den Möglichkeiten der Sprache überfordert und machen für ihr schlechtes/fehlendes Design die Programmiersprache verantwortlich.
Möglicherweise ist "C" für den Anwendungszweck von "Y" die bessere Wahl, weil einfach vieles der Funktionalität von C++ nicht benötigt wird. Wenn das Design halt zu diesem Schluss kommt, ist das doch völlig OK. Dann soll man das aber auch ehrlich sagen und nicht mit solchen Pseudoargumenten kommen.
Was heist Pseudoargumente? Die Argumente bezogen sich ja nur darauf wieso er C++ für Y nicht als sinnvoll betrachtet. Und auch wenn das ganze nicht so eindeutig drinsteht bezieht sich die Sache auf Seite 15 allein auf den Kern von Y. die Module und die Clientlibs können in jeder beliebigen Sprache geschrieben werden.
Ich verstehe nicht wieso jetzt hier alle gleich die beleidigte Leberwurst spielen müssen. Er hat doch nirgents geschrieben, dass C++ generell unbrauchbar ist sondern nur, wieso er es für Y nicht nutzen will und das hat er auch belegt. Muss er jetzt über alles 50 Seiten blabla schreiben blos damit irgentwelche C++ Fanatiker nichtsmehr zu meckern haben¿
Von El Pseudonymo am Sa, 21. Februar 2004 um 14:16 #
Also ich für meinen Teil bin nicht beleidigt.
Ich finde die Argument (speziell das was ich erwähnt habe) von ihm bloß nicht richtig. Und ich möchte wo immer es möglich ist, dagegen angehen das C++ unfair kritisiert wird. Das macht mich nicht zum "Fanatiker" (Auch wenn ich gegen den Ausdruck eigentlich gar nicht soviel hab...).
>C++ war auch nie als eierlegende Wollmilchsau konzipiert.
Aber es ist als das "bessere C" gedacht. Das Objekt modell ist ja nur ein Teil von C++ das ich nicht benutzen muss wenn ich nicht will. C++ ist eine Sprache die OO unterstützt aber nicht erzwingt, C++ unterstützt templates, erzwingt sie aber nicht usw.
Deswegen wird C++ oft als schlechte Sprache gesehen, weil es z.B. nicht 100% OO ist so wie Ruby.
Ich denke C++ ist nicht die schönste Sprache, aber die nützlichste.
Von El Pseudonymo am So, 22. Februar 2004 um 10:53 #
Ich kenne Eiffel nicht wirklich. Aber auch Eiffel wird höchstens automatisch zur Laufzeit prüfen ob der Objekttyp und der Zeigertyp kompatibel sind. Das bekommt man auch mit C++ sehr einfach hin.
Einige Dinge sind etwas unausgegoren und sehen fast so aus, als sucht er krampfhaft nach Erklärungen nicht C++ nehmen zu müssen ;)
Von abstrakten Basisklassen scheint er noch genauso wenig gehört zu haben wie von Dispatch-Tabellen mit union-Elementen. Wenn er zudem wirklich so "scharf" auf gescheite Ereignisbehandling ("Sender/Reciever") warum nimmt er dann nicht konsequenterweise Objectiv-C?
Ich denke der Junge hat nicht wirklich Ahnung und würde das auch einfach mal als Trollerei abtun. Soll er machen wie er denkt, ist schliesslich sein Projekt...
Du hattest wohl noch nie mit Systemprogrammierung zu tun, oder? C++ macht da potentiell Probleme, v.a. unter Unix. Auch wer sich um Kompatibilitaet von Software zwischen verschiedenen Unixen Gedanken macht, wird sich schnell von C++ verabschieden, und seine Software in reinem, POSIX- oder SuSv2/3-konformen C schreiben.
Wird nu schon wieder das rad neu erfunden ?? Hätten die nicht lieber einen fork vom bestehende X verwenden können? X modularisieren können ??
Bis aus diesem Projekt was benutzbares hervorgeht wird es jahre dauern !! und wenn einer nu sagt ich kann dem Projekt helfen dann muss ich leider sagen ich bin weder Programmierer noch habe ich geld,zeit um so ein Projekt unterstützen zu können!
> Machinenbauer lernen i.d.R. 9 Jahre das Modularisieren und am Ende können das nur 10%.
Während des Studiums? Sind da 18 Semester Regelstudienzeit? ;-)
> Warum sollten Informatiker es fertigbringen, wenn sie es nie gelernt haben?
Hmm, wer sich in seinem Studium mit Software Engineering/Component Engineering befasst und das auch praktisch anwendet, lernt da schon was über Modularisierung. Modularisierung läuft einem zumindest in der praktischen Informatik ständig über den Weg.
Von Johann von Nepomuk am So, 22. Februar 2004 um 23:49 #
4 jahre ingenieur schule - dabei 8 stunden pro Woche maschinenbau-elemente , ganze 4 jahre lang - das ist modularisieren lernen pur.
nachdem sie also wissen was und wie man etwas macht, erfahren sie 5 jahre auf der TH/Uni auch warum.
Und wie gesagt, am ende sind es ca. 10 %, die wirklich modularisieren koennen
Da aber modularisieren viel vom talent lebt, gibt es auch menschen, die in der informatik taetig sind , die super modilarisieren und nicht maschinenbauer sind. Genial=Thompson, Ritchie, Pike, sau gut=Torwalds, Cox
Ganz verrueckte denken sogar, dass man mit SQL modularisieren kann.
Für die Graphikroutinen wird die SDL benutzt. Kenn sich jemend damit aus? Wie funktioneirt das denn mit den Graphiktreibern - hängen die dann von X ab?
Mit den Grafiktreibern hat die SDL nix am Hut. Sie setzt auf die Plattformspezifische 3D-Lib. Unter Windows halt DirectX unter Linux OpenGL/Mesa. Ich weiss nicht genau wie Mausevents, Rootfenster (für das Rendersurface) usw. behandelt werden. Das könnte entweder mit den OpenGL/DirectX Funktionen oder mit der Xlib/Win-API geschehen.
Von Volker Ströbel am Fr, 20. Februar 2004 um 18:39 #
SDL setzt nicht auf OpenGL auf. Spiele, die z.B. auf OpenGL/SDL basieren machen genau das Gegenteil. Ohne SDL würden diese OGL garnicht erst nutzen können, da OGl (bzw GLX/MESA) keinen Zeichenbereich hätte, den es nutzen könnten, sie könnten keinerlei Auflösungen ändern usw...
SDL selbst greift bei den Graphikroutinen wenns auf X läuft direkt auf die libx (bzw einige extensions) zurück. SDL ist in keinster weise von OpenGL abhängig.
Auserdem ist DirectX keine 3D Lib sondern ne Sammlung verschiedenster Blibliotheken für verschiedneste Dinge. SDL greift unter Win32 für die Grafiksachen auf DirectDraw zurück und nicht auf Direct3D.
Jein Der Zeichenbereich etc. wird von der xlib gestellt (unter Windows von der Win-API). Wenn der Zeichenbereich erzeugt wurde, können die Direktiven von OGL genutzt werden. (Das Flag "SDL_OPENGL" initialisiert den GL-Mode beim setzen des Videomodes)
Es gab mal so einen Spruch das man ein Projekt alle 10 Jahre einreissen sollte und dann von 0 neu Anfangen. Die ganzen Erweiterungen die sich Aufgrund neuer Anforderungen immer mal ergeben machen aus einem ehemals sauber und gute designten Projekt schnell eine Bastelwerkstatt ;) Aus dieser Perspektive kann ich daher jedes neue "X" Projekt begrüssen. Entscheidend wird nur ob es auch den Break Even erreicht und die eigens gesteckten Ziele umsetzt. Bis jetzt sind alle Projekte in diesem Bereich mehr oder weniger eingeschlafen. Die Projekte die momentan am erfolgversprechendsten ausschauen (weil sie schon recht gut funktionieren) sind eigendlich nur der XServer von Freedesktop.org.
Problematisch ist vor allen die eigene Widget-Library direkt im Server. Das bedeutet das alles Toolkits angepasst werden müssten oder halt eine xlib-Emulierung her muss (die dann wieder mit dem angedachten Konzept bricht). Man muss einfach abwarten wie das ganze ausschaut wenn mal der Standardsatz an vllt. 30-40 Widgets implementiert ist und wenn es erste angepasste Anwendungen gibt... Auf jedenfall ein interessantes Projekt.
Na ja wenn die Arbeitslosigkeit unter Informatikern weiter so hoch bleibt, könnte es etwas werden. Aber der Schröder will uns ja zum Kartons stapeln nach Aldi vermitteln.
1. X Entwicklung bis zu einem festen Termin freezen. Sonst besteht kein Anreiz auf ein anderes System zu wechseln und es wird in 10 Jahren noch daran rumgeflickt. Ich halte diesen Punkt für am Wichtigsten. Wenn die Partner (siehe weiter unten) hier mitspielen nur dann wird das Projekt ein Erfolg. 2. Erst mal ein vernünftiges System _Analysieren_ dann designen und implementieren. Ein Standardset an Widgets muss heute drinn sein, wem das nicht gefällt kann immer noch sein Lieblingstoolkit nutzen. 3. Ein Kompatibilitätslayer für das alte X, sonst wird das Teil nie ein Erfolg werden. Nicht jede Software wird auf das neue System portiert werden. 4. Wichtige Partner ins neue Konsortium einbinden, als symbolische Zugpferde (Sun, SGI,IBM,Suse, Redhat,HP alle namhaften Unixfirmen, ausser SCO ;), damit die kommerziellen Softwarefirmen die bisher für X Entwickelten kapieren "Aha die sind auch dabei dann wird es ernst". 5. In C++ sehe ich heute kein Problem mehr da der gnu compiler auf allen wichtigen Platformen vorhanden ist. Auch ist er relativ weit was den Standard anbelangt. Man kann sich auch vorher überlegen welche Features der Sprache man nutzt und welche nicht wie das viele andere Projekte auch machen, dann geht man potentiellen Fallstricken gleich aus dem Weg. Allerdings hat der Typ nicht viel Ahnung von C++, wenn da mal die richtigen Leute mitmachen dann wird er das auch einsehen dass seine Vorbehalte eher auf Unkenntniss aufbauen.
Mal sollte sich vielleicht auch mal die anderen Projekte anschauen und analysieren warum die alle bisher gescheitert sind und daraus lernen, sonst wird das wieder ein Projekt für den Papierkorb.
So viele gescheiterte Projekte gibt es eigentlich gar nicht. Bekannt ist wohl nur den meisten "Fresco" und DirectFB. Bei beiden Projekten war wohl vor allem die Unterstützung moderner Grafikkarten das Problem. Mit nem VGA-Modus kann man heute keinen mehr hinterm Ofen hervorholen und entsprechende Treiber zu schreiben um Grakas auch accelerated und in der maximalen Auflösung zu nutzen, ist eine Wahnsinnsarbeit. Für DirectFB gabs sogar ein angepasstes GTK und einige Karten wurden sogar accelerated unterstützt. Was hats gebracht? Nix.
Genau an diesem Problem wird auch "Y" scheitern, es sei denn man hat ein Konzept wie man das mit den Treibern lösen will. Ohne Treiber für die meisten modernen Karten wird es auch keinen X-Ersatz geben.
Ob der neue Server nun X12 oder Y heisst, ist mir wurscht, Hauptsache er unterstützt Plug'N'Play und lässt sich dazu weiterhin per Konfigurationsfile zwingen, die Einstellungen zu nehmen, die ein (Firmen-)Administrator vorsieht. Das spart dann auch Zeit und nerven, die Auto-Erkennung auszulassen. Wenn man Windows zu so etwas zwingen könnte, wär es gut gewesen, aber es erkennt gern auf einmal neue Hardware und würfelt alles durcheinander.Ich bin froh, dass Linux immer/reproduzierbar genauso hochfährt, wie vorher auch, dazu soll auch der X-Login mit seinen Modelines gehören ;-)
Gegenüber kommerziellen X-Servern kann sicher einiges getan werden. Also die Render-Extension war nie schnell, um Schriften zu rendern, da läuft der von xig.com Kreise um XF86. Treiber müssen einfach zu basteln sein und schnell released werden können. Die Y-Spezifikation hört sich gut an und lässt auch weiterhin Windowmanager neben den beiden grossen DEs zu, die müssen nur ein wenig angepasst werden. Ich will keinen Einheitsdesktop und mir passt der Mix aus GTK2 und QT3 sehr gut, schöne Vielfalt und keine Langeweile.
Wenn dann noch der Bandbreitenverbrauch im Netzwerk durch ein neues Protokoll gedrückt werden kann, umso besser. Also Fonts AA, sonstiges AA und AF, dazu genaue Shader (statt z.B. derzeit subpixel accuracy der nVIDIA quadro) in CAD-Beleuchtungsmodellen, die Anforderungen sind hoch und während ein X11 wahrscheinlich nach und nach zurechtgerückt wurde, kann man mit Berücksichtigung der neuen Technologien ganz von vorn anfangen. So sieht doch Fortschritt aus. Man muss nicht sofort migrieren, aber ich bin gern weit vorn mit dabei
Habs mir mal angeschaut. Ist wirklich noch ganz am Anfang. Momentan läufts unter X11 in einem SDL-Fenster aber so wie ich gesehen habe ist auch ein reiner Framebuffer-Treiber vorhanden. Ein Term (modifiziertes iterm, die header der libiterm müssen separat installiert werden), eine einfache Uhr und ein einfachster Kalkulator gibts schonmal als Beispiel.
Die müssen vom Prinzip erstmal etwas vergleichbares wie GTK aufbauen, was dann aber direkt im Server und nicht beim Klienten läuft. Alleine das ist schon mal keine Kleinigkeit. Die Performance ist auch nicht so der Renner. Der XServer von Freedesktop erscheint mir performanter. Da haben die Jungs sich ja was vorgenommen. Na mal gucken wie der Zuspruch ist und vor allem wieviele Leute die finden die an dem Projekt mitmachen. Mit 2-3 Leuten wird das nämlich nix werden, es sei denn sie sind alle Arbeitslos und können sich 12h täglich dem Projekt widmen ;)
mir scheint das irgendwie so: while(1) { std::string name=generate_x_successor().name(); pro_linux.post_news_stream()<<name<<" loest XWindows ab"<<news::post; current_proccess()->sleep(some_time()); }
Na komm, so viele "X11"-Projekte gibt es ja nun auch nicht. An ablösen von X-Window denkt nun wirklich auch keiner, wenn man den aktuellen Status des Projektes sieht. Einige Designmerkmale sprechen eher stark dafür das es das Projekt nicht lange geben wird oder so vor sich hindümpelt wie Fresco.
Vor sechs Jahren hat schonmal jemand begonnen, ein Y Window System zu schreiben. Herausgekommen ist nichts dabei.
Sicher hat Mark Thomas recht, daß die Codebasis von X11 in einem schlimmen Zustand ist. Aber einen neuen Server zu schreiben, ist nur der Anfang. Wer schreibt alle Clients um?
Ebend. Nicht machbar, zumal auch nicht wirklich ein Grund besteht. Es gibt Treiber für nahezu alle Karten unter X11, es kann gezockt werden und die normalen Anwendungen laufen recht performant. Sinnvoller scheinen wirklich Forks zu sein, die im inneren von X11 aufräumen und nach aussen (Xlib) unverändert bleiben.
so sehe ich das auch. Ein Anfang ist gut, aber es gab da schon einige Anfänge. Und jeder Ansatz der nicht 100% perfekt mit KDE und GNOME läuft, hat 0 Chancen unter Linux. Ein eigenes Toolkit? Schonwieder? Ne, also das lässt er mal besser bleiben ;) Zumal Linux mit GTK und QT bereits nurnoch 2 wichtige Toolkits hat, die sich inzwischen auch stark anhähern.
Wobei ein sauberes X schon etwas schönes wäre. Aber so ein Radikalschnitt, ich glaube nicht das soetwas uns weiterbringt. Dafür haben zu wenig Leute interesse an der Arbeit auf dieser Schicht, als das sich genug Leute finden würden die es auch über Jahre vorranbringen :/
Das Konzept ist zwar nicht schlecht, aber nicht zu Ende gedacht. Anstatt Energie in das schreiben eigener Widgets zu stecken, sollte man eher erstmal eine Xlib-Kompatibilitätslib schreiben damit sofort alle Anwendungen laufen. Das würde zumindest auch vielen zeigen "Hej, das könnte was werden, denn alle Anwendungen laufen schon". Danach ist es viel wichtiger Treiber von X11 zu portieren, zumindest für die wichtigsten Karten (Nvidia, Ati). Dann kann man sich in aller Ruhe hinsetzen und ne richtig feine Widget-Library in den Server packen. Dazu noch eine eine feines Toolkit und paar Beispielportierungen. Wenn das wirklich gut aussieht werden die Maintainer schon auf den Zug aufspringen.
Das Teil steht unter der GPL also bitte.
Bescheuert, wenn ihr mich fragt.
Andererseits, "Gimp", "Gnu" und Konsorten sind ja auch nicht besser.
Wenn man es englisch ausspricht klingt es doch ganz witzig:
'why windows'??? :-D
Gruß,
nano
Das bezog sich auf den Betreff.
Die Domain heißt übrigens in der Tat y-windows.org. ;-)
Gruß,
nano
Wer soll denn die Milliarden Zeilen Code auf das neue grafische System portieren?
Selbst wenn sich Y/BerliOS/... wirklich jemals verbreiten würden, hätten wir dann wohl für Jahre alle zwei grafische Systeme installiert, mit eigenen Konfigurationen, Inkompatibiltäten, ... und darauf freue ich mich wirklich nicht.
Ich glaube der einzig vernünftige Weg, der allem Anschein nach auch eingeschlagen wird, ist X (in einem neuen, fexibleren Entwicklungsmodell) weiterzuentwickeln.
Es wird zwar schon diskutiert, es unter die LGPL zu stellen, doch XFree ist - zumindest mit seiner alten Lizenz v. 1.0 - viel liberaler.
Vor allem den BSDs dürte somit die GPL/LGPL-Lizenz wohl wenig gefallen.
Warum??
Mit der LGPL gibt es da überhaupt keine Probleme! Du darfst es gegen alles linken nur das LGPL Programm selber muß frei sein und das finde ich auch gut, man muß ja nicht alles an die Industrie verscherbeln die dann einen haufen Kohle damit machen und nie etwas zurüxk kommt.
Selbst mit der GPL sollten die BSD Leute keine Probleme haben da ihre Lizenz GPL Kompatibel ist...
sonst könnte man ja über den umweg über bsd aus nem gpl ding ein kommerzielles machen da man soweit ich weiß aus nem bsd-programm alles klauen darf.
Naja kann auch sein das ich das falsch verstanden habe, bitte dann um aufklährung.
D.h. mann kan BSD Lizensierten code in GPL lizensierten einbauen, man kann BSD Programme gegen GPL libs linken,...
Wenn ich BSD code und GPL code zusammeführe ist es ganz einfach. Solange es zusammen ist überwiegt die "restriktivere" Lizenz, d.h. ich darf das gesammte nach den Richtlinien der GPL verwenden. Ich kann natürlich jederzeit den BSD Teil rausnehmen und damit dann alles machen was mir die BSD Lizenz erlaubt.
Dass mit der Lizenz von Qt keine Möglichkeit für ein KDE unter LGPL bestand rächt sich spätenstens jetzt...
Und nochwas: wenn man das Grafische System neu zusammenschrauben will: gehe man doch den OS X-Weg - etwas Besseres wird man schwer finden können...
Auch die KDE bzw. QT libs koennen fuer kommerzielle Dinge verwendet werden!
>ein KDE unter LGPL bestand rächt sich spätenstens jetzt..
KDE steht unter der GPL, gnome auch... und das ist auch gut so.
Irgendwie habe ich das gefuehl, dass du nicht wirklich Ahnung hast wovon du sprichts...
Aber worum es hier geht ist nicht Gnome - sondern nur dessen Libs - GTK also - und diese stehen unter LGPL - was das Verwenden in kommerziellen Anwendungen ohne Weiteres möglich macht - deshalb der Einsatz auf Suns Java-Desktop und bei Userlinux
Dagegen: KDE (dessen Libs) basiert auf QT - das unter der GPL steht - womit kommerzielle anwendugen nicht möglich sind, ohne den Quellcode zu veröffentlichen (das wird nicht jeder hinnehmen) - alternativ kann man sich die QT-Libs ja auch lizenzieren (mit Geld) - und weil Geiz heutzutage Geil ist, nehmen viele lieber GTK.
War das jetzt wirklich so schwer zu verstehen?
> (*unbeguerndete_behauptungen*)
Was Du hiermit zu sagen versuchst, ist mir nicht ganz klar.
Nichts für ungut.
Auch QT libs, oder libs allgemein unter der GPL koennen in kommerziellen Anwendungen verwendet werden!
>War das jetzt wirklich so schwer zu verstehen?
Du hast vorher nicht von den libs gesprochen sondern das hier geschrieben:
"Dass mit der Lizenz von Qt keine Möglichkeit für ein KDE unter LGPL bestand rächt sich spätenstens jetzt..."
und das ist einfach falsch! Da man KDE unter die LGPL haette stellen koennen!
>> (*unbeguerndete_behauptungen*)
>Was Du hiermit zu sagen versuchst, ist mir nicht ganz klar.
ich halte es fuer eine unbegruendetet und unhaltbare Behauptung das gnome der "weniger weit entwickelte Desktop" ist. Dir gefaellt KDE oder dessen Entwicklungsrichtung besser? OK, aber weil dir KDE besser gefaellt muss gnome nicht schlechter sein.
Ausserdem halte ich von beiden (Suns Java-Desktop und Userlinux) nicht viel.
Und mir gefallen die QT libs besser wie die GTK libs, nicht weil sie vielleicht technisch besser sind (was ich auch garnicht glaube) sondern wegen der Lizenz.
Ich finde die Lizenzpolitik von QT super und sie gibt uns in der free Software community dadurch auch einen gewissen Vorteil und schuetzt uns vor crippleware wie z.B. Leute die meinen nur weil GNU/Linux etwas bekannter wird ploetzlich dafuer shareware oder freeware zu entwickeln...
Man könnte sie also mit Nicht-GPL-Qt nutzen.
Nicht ganz, sie sind neben der GPL noch unter der QPL (oder so ähnlich) lizensiert.
Die QPL ist der LGPL ziemlich ähnlich, erlaubt aber keine proprietären Programme sondern nur Programme unter einer anderen freien Lizenz (z.B. modifizierte BSD Lizenz, (alte) X11, MIT Lizenz,...)
stimmt, die KDE libs stehen unter der LGPL, war mein Fehler, ich habe bei "libs von KDE" zuerst an QT gedacht...
Ich denke, dass er sich dessen bewusst ist.
Solche Behauptungen werden praktisch immer absichtlich verbreitet.
Das Ziel dürfte sein, Menschen mit nur oberflächlichen Interesse an der Thematik zu verunsichern.
>Solche Behauptungen werden praktisch immer absichtlich verbreitet.
Du hast meine Antwort darauf gelesen? Nein! Sonst würdest du nicht so einen sch*** erzählen, dass ich absichtlich falsche Informationen streuen würde...
Es ist vielleicht besser wenn man erstmal einen Thread ließt bevor man meint seinen Senf dazugeben zu müssen!
Du hast ja die Information richtig gestellt.
Damit fällt die Entwicklung geschlossener, kommerzieller Applikationen für QT flach, sofern man nicht auf die QPL (so hieß sie glaube ich) zurückgreift. Für die verlangt Trolltech natürlich Geld (wie Lord Zwiebel schon schrieb).
PS: "Besser als", nicht "besser wie". (:
PPS: "lizenzieren", nicht "lizensieren". <:
und der QPL, welche dir erlaubt auch gegen andere freie Lizenzen zu linken. Damit kann man z.B. auch Programme unter der BSD, MIT, X11,... lizenz entwickeln!
>Damit fällt die Entwicklung geschlossener, kommerzieller Applikationen für QT flach
Die Entwicklung proprietärer Software fällt flach! Kommerzielle kann man damit ohne Probleme entwickeln!
Und warum sollte jemand der die Rechte des users bei seiner eigenen Entwicklung nicht berücksichtigt verlangen können das seine eigenen vom Toolkit Hersteller berücksichtigt werden? Ich finde die Lizenzen Politik von Trolltche super!
>sofern man nicht auf die QPL (so hieß sie glaube ich) zurückgreift.
du meinst die "Qt Commercial License", die QPL ist eine freie Lizenz
Mag schon sein, dass Firmen Geld sparen wollen aber so ein paar QT-Lizenzen kosten doch verhältnismäßig wenig...
Mit gefällt der sachliche GTK-Stil einfach besser als das bonschiege GNOME oder das noch viel üblere KDE.
X != XFree
Daran haben sich schon andere die Zähne ausgebissen und sind gescheitert. So eine Geschichte wie der Xserver von Freedesktop.org hat da eher Chancen, weil er auf die xlib aufsetzt und damit auch alle Anwendungen von KDE bis Gnome ohne Probleme sofort laufen. Allerdings besteht hier natürlich auch das Treiberproblem - eigentlich das einzige Problem was immer vorhanden ist und neue Konzepte fast unmöglich macht.
Das halte ich für kein (großes) Problem. Eigentlich laufen so gut wie alle Grafikkarten mit freien Treibern und auch 3D geht wenn man sich die richtige Grafikkarte aussucht. Z.B. gibt es afaik für ATI und Matrox Karten freie Treiber die 3D-beschleunigung unterstützen.
Das ist nur ein Problem wenn man sich von Firmen wie nvidia abhängig macht und irgendwann sogar anfängt zu glaube das diese Abhängigkeit die einzige Lösung ist.
Aber dann hätte man in den Anfangstagen von GNU/Linux auch argumentieren können das es nie eine chance hat, da es kaum brauchbare Programme dafür gab...
ich denke es wäre dennoch umfangreich die Treiber von X nach Y zu portieren. Dann noch die ganzen Fehlerchen die sich einschleichen, ist ja nicht gleich alles stable. Cooler wärs würde Y gleich die X-Treiber schlucken
Ausserdem ist der Typ nicht Keith Packard oder hat sonstwie Erfahrung mit solchen Systemen. Der fängt quasi bei Null an und muss selbst noch viel lernen...
Um sowas durchzuziehen müssten alle Xfree-Experten dort mithelfen. Wenn Packard und andere sich dem Projekt anschliessen würden dann könnte es was werden.
Ein Resultat der globalen Erwaermung?
nu"schwimmwestesuchend"fap
> Meinung nach zu inflexibel, langsam, verfügt über kein Standard-Toolkit und
> macht den Programmierern viel zu viel Arbeit. Thomas sei fest davon
> überzeugt, dass die Zeit gekommen ist, das altgediente X durch ein modernes
> System zu ersetzen.
Also meiner Meinung nach, wird es wohl nichts.
Es stimmt schon, daß ein Standard-Toolkit von Vorteil ist. Jedoch ist dafür das Betriebssystem Linux (genauso wie FreeBSD, OpenBSD, etc) nicht für geschaffen.
Die Idee hinter Linux ist die Auswahl zu haben. Indem das Toolkit vorgeschrieben wird, fällt diese Auswahl weg. Und sofern überhaupt etwas eng mit Linux verbunden ist, so wäre es höchstens die grafische Oberfläche. Wenn man die nun ducrh etwas anderes austaucht, dann ist fast schon wie ein neues Betriebssystem.
Ich mein, es wurde ja auch schon die grafische Oberfläche von AtheOS (inzwischen Syllable genannt) auf Linux portiert und Cosmoe genannt.
Trotzdem ist Syllable wohl - sofern man von Populatität reden kann - um einiges populärer und "verbreiteter" als Cosmoe.
Es gibt viele Betriebssysteme, bei denen nun die grafische Oberfläche direkt auf dem Kernel aufsetzt. Dort sind dann auch die meisten Kommandozeilenprogramme meist direkt als GUI-Programme vertreten.
Es gibt Betriebssysteme bei denen somit der Kernel, die grafische Oberfläche und die Widgets eins sind. Noch dazu mit einer Startleiste. Als Beispiele wären hier Windows und BeOS zu nennen, die es in Zukunft wohl auch als ReactOS und OpenBeOS als OpenSource gibt. (Wobei Spiegel.de heute sogar über ReactOS berichtet hat).
Der Vorteil dieser Verschmelzungen ist, daß man dadrauf zugreifen kann. Ein Programmierer weiß, daß unter Windows die Windows-Startleiste zur Verfügung steht und man dort sein Icon integrieren kann. Das selbe gilt für BeOS.
Aber bei Linux kann es sein, daß das KDE-Panel dort ist, daß das GNOME-Panel dort ist oder jemand erst garkein Panel auf seinem Desktop hat.
Somit müßte man auch ein Panel direkt mit ins Y-Windows integrieren.
Dieses würde jedoch direkt wieder als Konkurrenz zum KDE und GNOME-Panel stehen.
Desweiteren werden wohl noch immer viele Personen, auf manchen Rechnern erst garkein X oder Y draufhaben.
Anders ist es bei BeOS und Windows.
BeOS kann man nicht im CLI-Modus starten. Terminalbefehle wie "alert", die man in ein Shell-Skript integrieren kann, öffnen grundsätzlich ein Fenster. Und jeder Entwickler weiß, daß wenn er ein Shell-Skript schreibt, das aler aufruft, daß alert auch zur Verfügung steht.
Ein ähnliches Programm scheint es von Sun auch für den GNOME2-Desktop zu geben. Aber Linux-Entwickler werden es wohl kaum nutzen, denn es könnte auch sein, daß GNOME nicht installiert ist.
Insofern sehe ich schon einen Vorteil eines einheitlichen Desktops.
Aber Y geht wohl zum einen nicht weit genug, zum anderen ist es die falsche Zielgruppe. Besser wäre es komplett einheitliches System, das neu entwickelt wurde.
Sven
Woher willst Du wissen, dass unter Windows, Kernel, GUI und Widget eins sind? Das glaube ich eher nicht. Lasse mich aber gerne belehren. Windows kommt ja im Gegensatz zu Linux nicht aus einer monolithischen Kernelkultur.
http://c2.com/cgi/wiki?MicroKernel
"Mach, WindowsNtKernel?, GnuHurd and DarwinOs (kernel of MacOsx) are examples of MicroKernel. -- TakuyaMurata ...
WindowsNtKernel? is also not actually a microkernel, although it was marketed as a microkernel when microkernels were fashionable. For example, the NT executive (aka the kernel) is implemented above a hardware abstraction layer. In a true microkernel OS, the kernel itself is the hardware abstraction layer. And now, since the graphics and GUI components have been moved into kernel space, NT is even less of a microkernel OS."
Aber es gehört nun mal alles mit zum System (zumindest bei Windows NT und Nachfolger, denn bei Win95/Win98 kann man auch den DOS-Modus starten, dann hat man soetwas wie Linux ohne X oder Y).
Somit startet Windows NT, Win2k, WinXP, etc gegenüber Linux direkt im grafischen. Und etwas anderes ist auch nicht möglich (bei BeOS genauso).
Und auch die Startleiste (die, wo wenn man aus "Start" klickt, direkt dadrüber etwas hat, wo "Beenden" steht) ist auch ein Teil des installierten Systems (ähnliches gibt es auch bei BeOS). Und unten rechts neben der Uhrzeit können dann Applikationen die gerade laufen (wie Outlook, Soundsteuerung und so) sich als kleine Icons verewigen. (ähnliches gibt es auch bei BeOS)
Bei Linux ist es jedoch in der Form nicht so leicht möglich. Dann müßte der Entwickler festlegen, daß bei einem GNOME1-Panel das Icon im GNOME1-Panel sitzt, bei einem GNOME2-Panel im GNOME2-Panel beim KDE3-Panel im KDE3-Panel und bei den anderen KDE versionen ebenso. Und man müßte berücksichtigen, was passiert, wenn kein Panel vorhanden ist.
Einer der netten Features bei einem Panel das zum System gehört, sieht man bei Windows beim Programm Outlook (man kann von Outlook halten, was man will, aber dieses Feature ist gut):
Wenn bei Outlook Mail reinkommt, dann erscheint unten rechts auf der Startleiste ein kleier Briefumschlag. Sehr nützlich, wenn man gerade andere Programme auf hat.
Ähnliches gibt es auch bei Netscape, doch ist es dort nur auf das Netscape-Fenster beschränkt. Das heißt, wenn ich gerade im Internet surfe, sehe ich bei Netscape unten im Fenster, daß Mail gekommen ist. Wenn ich jedoch stattdessen ein anderes Programm gerade offen habe und Netscape minimiert wurde, dann sehe ich nicht mehr, wenn Mail reinkommt.
Sven
Ob nun ein Symbol in der Kontrollleiste erscheint hängt immernoch vom Fenstermanager ab, und das soll auch so bleiben.
Das was du meinst sind wohl eher Bibliotheken die eine Schnittstelle für Nicht-KDE oder Nicht-Gnome Programme Funktionalitäten von KDE / GNome ermöglichen. Die Realisierung hängt aber vom Fenstermanager ab und KDE hat sowas schon integriert (kio-plugins).
GUI soll einfach nur darstellen, sonst nix.
was die Installation von Programmen angeht:
Dann müsste man endlich wegkommen von der Praxis, dass die Programme sagen, wohin sie sich installieren wollen (läuft ja eh schon bei Windoof schief), und hin zu einer standartisierten Struktur (Verzeichnisse, Files, etc.), damit danach GNOME, KDE und Co. die Programme zuerst in die Programmliste und der Anwender danach diese in das Dock/Kontrollleiste/whatever aufnehmen kann.
Welche Auswahl hat man denn? X und...
Doch nicht etwa Framebuffer, ach jetzt weiß ich, die KOmmandozeilte
Gemeint waren Toolkits, also motif, qt, gtk, wxwindows, tk, swing (um nur die bekanntesten von dennen zu nennen).
>Doch nicht etwa Framebuffer, ach jetzt weiß ich,
> die KOmmandozeilte
Schwachsinn.
Diese Auswahl hat man auch bei Windows.
Der große Vorteil unter Windows ist, dass die Anwendungen für den Anwender gleich aussehen, egal ob MFC, Qt, Swing oder sonstwas verwendet wurde. Und so sollte es auch sein. Was interessiert es den Anwender, in welcher Programmiersprache und mit welchem Toolkit der Entwickler hantiert?
Aber zumindest wird man weitgehend mit Totalschrott verschont.
Athena-Widgets, TK, Motif oder Motif-Clones z.B. gehören entsorgt.
Aber man muss sich unter Linux immer noch damit rumquälen. Z.B. bei Adobe A-Reader.
Oder X-Emacs. Ein erbärmlicheres GUI kann sich für die eierlegende Wollmilchsau doch gar nicht finden lassen.
Aber bei Linux kann es sein, daß das KDE-Panel dort ist, daß das GNOME-Panel dort ist oder jemand erst garkein Panel auf seinem Desktop hat.
Was durch das Debian-Menu-System schon lange überhaupt gar kein Problem mehr darstellt.
anderes Beispiel: Mozilla/Firefox-Download-Manager. Show File location. Was machen unter Linux? Einfach den Punkt aus lauter Hilflosigkeit deaktivieren. Unter Windows poppt der Explorer auf.
Zahlreiche weitere Bsp. lassen sich finden.
"Various levels of access. Different languages and different environments
provide different communication primitives. High level object-based languages
might best interface with Y at the object level, utilising their own
object communication system. At a lower level, systems that provide
fast message passing should be able to use this as their primary communications
primitive. Finally, it should be possible to communicate with
the server using socket connections, as this is the level at which network
transparent applications will be able to communicate with the server."
Ist aber ausreichende bekannt, solche "Horrorgeschichten" werden meist absichlicht verbreitet.
X11 ist meiner Meinung nach überhaupt nicht "langsam" (wobei Geschwindigkeit die Menge an Grafikprimitiven pro Zeiteinheit ist, die ein Client lokal zeichnen kann). Das was der Benutzer als langsam empfindet kommt meißt durch ganz andere Sachen. z.b. die Toolkits (kdelibs z.b. die qt ja noch um einiges aufblähen), die enorme anzahl an Libraries die manche Programme benutzen und teilweise auch die uneffiziente Programmierung von Toolkits (was zugegeben durch die Xlib auch ziemlich kompliziert ist)
Die Gründe, die er gegen C++ aufführt sind keineswegs mau. Vielleicht findest du sie irrelevant aber andere Leute sehen das eben anders und das auch zurecht. Ich persönlich finde viele Scachen an C++ auch zu kotzen. Es ist zwar nicht übel, aber perfeckt ist es keineswegs...
Zum Beispiel auf Seite 15 des Reports:
"[...] pointers to members cannot be subsumed under the type of ther receiver [...], that is a member pointer '&Canvas::drawLine' which is of type 'void Canvas::* (...)' cannot be safely converted to a pointer of type 'void Object::* (...)' even though 'Canvas' inherits from 'Object'. "
Nun, dafür gibt es gute Gründe. Wenn er das als Grund nimmt, nicht C++ zu verwenden könnte, man das als Trollerei bezeichnen, denn egal welche Programmiersprache er nimmt, diese Einschränkung müßte er eigentlich in jeder nachbauen.
OO-Sprachen die auf Nachrichtenebene arbeiten und echte dynamische/späte Bindung beherrschen (also nicht die Krüppellösung die man unter C++ als late binding bezeichnet) haben dieses Problem meistens nicht.
IPC/RPC mit Objekten unbekannten dynamsichen Typs lässt sich zwar bei C++ auch per RTTI und änliche Geschichten hinbastelt, was aber aufgrund der psuedodynamsichen Bindung, die direkt auf ebene der Funktionsaufrufe realisiert ist, nicht gerade schön zu realisieren ist. Erschwerend wird es, wenn die Zielobjekte und deren Kommunikationsschnittstellen zur Übersetzungszeit völlig unbekannt sind und deshalb keinerlei Prototypisierung möglich ist um den dynamischen Datentyp zu erlangen.
Auch ist eine dynamsiche Vererbung zur Laufzeit im C++ Objektmodell nicht realisierbar.
Viele Bibliotheken, die unter C++ IPC, RPC und Signalbehandlung bereitstellen hüpfen generell zwischendurch immer wieder aus dem Objektmodell von C++ heraus, da vieles ansonsten garnicht erst realisierbar wäre.
Sicherlich, man kann alles mehr oder weniger sauber auch mit C++ machen. Aber wieviel bleibt mir dann noch von C++ übrig, wenn ich sowieso überall irgentwelche dreckigen Hacks reinbasteln muss. Hier geht es ja auch nur um den Kern. In welcher Sprache die Module geschrieben werden ist dank C auch ziemlich egal. Mit C++ müsste man hier auch wieder die ABI mit ner C Bindung aussatten oder man baut wieder irgentwelche dreckigen Sachen ein um die C++ Namesauflösung zu umgehen und um das C++ Objektmodell zu verstecken.
Für Y ist es nur wichtig einen möglichst kleinen, flexiblen und sauberen Kern zu haben um den sich dann die Module rumtümmeln. Und ob C++ dafür wirklich so sinnvoll ist bezweifle ich bezüglich der gegebenen Probleme sehr.
Nein, das glaube ich nicht. Wenn man einen Zeigertyp auf eine Methode einer abgeleiteten Klasse hat, dann kann man durch diesen Typ immer Methoden aufrufen die in einer Basisklasse nicht vorkommen. Das ist ein ziemlich universeller Sachverhalt der bei weitem nicht auf C++ beschränkt ist. Man muß sich auch bei anderen Sprachen in vergleichbaren Fällen erst versichern das das Objekt für das die Methode gerufen wird den passenden Typ hat.
Es ist aber nur bei Sprachen vorhanden, die eine funktionsbassierende Methodenbeding nutzen (wie eben C++). Bei Nachrichtenbasierter Methodenbindung ist das ganze in der Regel egal.
In einigen Sprachen kann ich Nachrichten an ein Objekt schicken wie ich lustig bin. Der Typ des Objektes ist dabei völlig irrelevant. Versteht das Objekt diese Nachricht wird sie abgearbeitet, versteht es sie nicht wird ne Fehlermeldung zurückgeliefert. Dazu ist natürlich ein RTE nötig, das diese Sachen behandelt.
Und genau das passiert bei Y. Die eigene Objektsystem ist in diesem Falle das RTE für die IPC/RPC und die Module. Das Ganze auf C++ aufzusetzen, wäre als wenn ich nem Schwein mit Flügeln ein zweites Paar Flügel dranbasteln und das erste Paar mit Heftklammern im A... befestige.
Aber besonders stichhaltig finde ich das trotzdem nicht. C++ hat über C ja noch mehr zu bieten als nur OOP im besprochenen Sinn.
Außerdem kann ein Nachrichtenbasiertes RTE ja durchaus mit den OOP Features die C++ hat koexistieren. Dann hätten in C++ geschrieben Anwendungen immer noch den Vorteil dieses RTE eventuell nicht benutzen zu müssen, während es, sollte es nötig sein, bereitsteht.
Ich perönlich zweifel auch daran, das eine solche "Full-Blown" Middleware noch einmal extra für ein Graphisches Desktop System Sinn macht. Es gibt ja schon so viele. Aber das ist natürlich (genauso wie die Wahl der Sprache) Sache von den Entwicklern.
Die Anwendungsenwickler kriegen davon überhaupt nichts mit, da die Clientlibs das ganze höchstens tangiert, aber keine direkte auswirkungen auf sie hat.
Und die Leute, die Module schreiben sehen nur eine C schnittstelle, die sich z.B. für C++ Module auch noch mit nem Modultemplate so verzieren lassen dürfte, dass sich C++ Programmierer auch heimisch fühlen.
Was die nicht OOP Erweiterungen von C++ angeht so muss man in dem Fall natürlich mit einbeziehen, dass man diese Teilweise auch über C99 nutzen könnte (was aber bei einigen Compilern zu kleinen Problemen führen könnte) und das man dann dennoch versuchen müsste eine möglichst Sprachunabhängige Modulschnittstelle zu bekommen, was bei C++ durchs name mangling nicht gerade sehr einfach ist.
Das mit den dynamischen Typen funktioniert sehr gut zur Laufzeit wenn man sich auf eine Zwischensprache zur Beschreibung der Schnittstellen und Typen festlegt. IDL mit COM sei nur mal ein Beispiel.
Alles eine Sache des Designs. Abstrakte Basisklassen sind z.B. kein dirty Hack zum umgehen der Namensauflösung sondern sogar aus OO-Sicht eine sehr saubere Lösung. Die meisten sind einfach mit den Möglichkeiten der Sprache überfordert und machen für ihr schlechtes/fehlendes Design die Programmiersprache verantwortlich.
Möglicherweise ist "C" für den Anwendungszweck von "Y" die bessere Wahl, weil einfach vieles der Funktionalität von C++ nicht benötigt wird. Wenn das Design halt zu diesem Schluss kommt, ist das doch völlig OK. Dann soll man das aber auch ehrlich sagen und nicht mit solchen Pseudoargumenten kommen.
Die Argumente bezogen sich ja nur darauf wieso er C++ für Y nicht als sinnvoll betrachtet. Und auch wenn das ganze nicht so eindeutig drinsteht bezieht sich die Sache auf Seite 15 allein auf den Kern von Y. die Module und die Clientlibs können in jeder beliebigen Sprache geschrieben werden.
Ich verstehe nicht wieso jetzt hier alle gleich die beleidigte Leberwurst spielen müssen. Er hat doch nirgents geschrieben, dass C++ generell unbrauchbar ist sondern nur, wieso er es für Y nicht nutzen will und das hat er auch belegt. Muss er jetzt über alles 50 Seiten blabla schreiben blos damit irgentwelche C++ Fanatiker nichtsmehr zu meckern haben¿
Ich finde die Argument (speziell das was ich erwähnt habe) von ihm bloß nicht richtig. Und ich möchte wo immer es möglich ist, dagegen angehen das C++ unfair kritisiert wird. Das macht mich nicht zum "Fanatiker" (Auch wenn ich gegen den Ausdruck eigentlich gar nicht soviel hab...).
Aber es ist als das "bessere C" gedacht. Das Objekt modell ist ja nur ein Teil von C++ das ich nicht benutzen muss wenn ich nicht will. C++ ist eine Sprache die OO unterstützt aber nicht erzwingt, C++ unterstützt templates, erzwingt sie aber nicht usw.
Deswegen wird C++ oft als schlechte Sprache gesehen, weil es z.B. nicht 100% OO ist so wie Ruby.
Ich denke C++ ist nicht die schönste Sprache, aber die nützlichste.
Von abstrakten Basisklassen scheint er noch genauso wenig gehört zu haben wie von Dispatch-Tabellen mit union-Elementen. Wenn er zudem wirklich so "scharf" auf gescheite Ereignisbehandling ("Sender/Reciever") warum nimmt er dann nicht konsequenterweise Objectiv-C?
Ich denke der Junge hat nicht wirklich Ahnung und würde das auch einfach mal als Trollerei abtun. Soll er machen wie er denkt, ist schliesslich sein Projekt...
Die System API ist ohnehin in C, die Applikation kann man ohne Probleme in C++ machen.
Qt ist bekanntlich eine C++ Bibliothek und trotzdem auf zahlreichen Unix Systemen verfügbar.
Früher war das sicher problematisch, als es noch keinen vernünftigen C++ Standard gab.
Hätten die nicht lieber einen fork vom bestehende X verwenden können?
X modularisieren können ??
Bis aus diesem Projekt was benutzbares hervorgeht wird es jahre dauern !!
und wenn einer nu sagt ich kann dem Projekt helfen dann muss ich leider sagen ich bin weder Programmierer noch habe ich geld,zeit um so ein Projekt unterstützen zu können!
gruß ypsylon
Unrealistisch.
Machinenbauer lernen i.d.R. 9 Jahre das Modularisieren und am Ende können das nur 10%.
Warum sollten Informatiker es fertigbringen, wenn sie es nie gelernt haben?
Weil sie den unschlagbaren Vorteil haben, solange daran herumschrauben zu können, bis es (irgendwann) geht...
Während des Studiums? Sind da 18 Semester Regelstudienzeit? ;-)
> Warum sollten Informatiker es fertigbringen, wenn sie es nie gelernt haben?
Hmm, wer sich in seinem Studium mit Software Engineering/Component Engineering befasst und das auch praktisch anwendet, lernt da schon was über Modularisierung.
Modularisierung läuft einem zumindest in der praktischen Informatik ständig über den Weg.
nachdem sie also wissen was und wie man etwas macht, erfahren sie 5 jahre auf der TH/Uni auch warum.
Und wie gesagt, am ende sind es ca. 10 %, die wirklich modularisieren koennen
Da aber modularisieren viel vom talent lebt, gibt es auch menschen, die in der informatik taetig sind , die super modilarisieren und nicht maschinenbauer sind.
Genial=Thompson, Ritchie, Pike, sau gut=Torwalds, Cox
Ganz verrueckte denken sogar, dass man mit SQL modularisieren kann.
Wie funktioneirt das denn mit den Graphiktreibern - hängen die dann von X ab?
Ich weiss nicht genau wie Mausevents, Rootfenster (für das Rendersurface) usw. behandelt werden. Das könnte entweder mit den OpenGL/DirectX Funktionen oder mit der Xlib/Win-API geschehen.
Spiele, die z.B. auf OpenGL/SDL basieren machen genau das Gegenteil. Ohne SDL würden diese OGL garnicht erst nutzen können, da OGl (bzw GLX/MESA) keinen Zeichenbereich hätte, den es nutzen könnten, sie könnten keinerlei Auflösungen ändern usw...
SDL selbst greift bei den Graphikroutinen wenns auf X läuft direkt auf die libx (bzw einige extensions) zurück. SDL ist in keinster weise von OpenGL abhängig.
Auserdem ist DirectX keine 3D Lib sondern ne Sammlung verschiedenster Blibliotheken für verschiedneste Dinge. SDL greift unter Win32 für die Grafiksachen auf DirectDraw zurück und nicht auf Direct3D.
Jein
Der Zeichenbereich etc. wird von der xlib gestellt (unter Windows von der Win-API). Wenn der Zeichenbereich erzeugt wurde, können die Direktiven von OGL genutzt werden.
(Das Flag "SDL_OPENGL" initialisiert den GL-Mode beim setzen des Videomodes)
Aus dieser Perspektive kann ich daher jedes neue "X" Projekt begrüssen. Entscheidend wird nur ob es auch den Break Even erreicht und die eigens gesteckten Ziele umsetzt. Bis jetzt sind alle Projekte in diesem Bereich mehr oder weniger eingeschlafen.
Die Projekte die momentan am erfolgversprechendsten ausschauen (weil sie schon recht gut funktionieren) sind eigendlich nur der XServer von Freedesktop.org.
Problematisch ist vor allen die eigene Widget-Library direkt im Server. Das bedeutet das alles Toolkits angepasst werden müssten oder halt eine xlib-Emulierung her muss (die dann wieder mit dem angedachten Konzept bricht). Man muss einfach abwarten wie das ganze ausschaut wenn mal der Standardsatz an vllt. 30-40 Widgets implementiert ist und wenn es erste angepasste Anwendungen gibt...
Auf jedenfall ein interessantes Projekt.
Aber der Schröder will uns ja zum Kartons stapeln nach Aldi vermitteln.
besteht kein Anreiz auf ein anderes System zu wechseln
und es wird in 10 Jahren noch daran rumgeflickt.
Ich halte diesen Punkt für am Wichtigsten. Wenn die Partner
(siehe weiter unten) hier mitspielen nur dann wird das Projekt
ein Erfolg.
2. Erst mal ein vernünftiges System _Analysieren_ dann designen
und implementieren. Ein Standardset an Widgets muss heute drinn
sein, wem das nicht gefällt kann immer noch sein Lieblingstoolkit
nutzen.
3. Ein Kompatibilitätslayer für das alte X, sonst wird das Teil
nie ein Erfolg werden. Nicht jede Software wird auf das neue
System portiert werden.
4. Wichtige Partner ins neue Konsortium einbinden, als symbolische
Zugpferde (Sun, SGI,IBM,Suse, Redhat,HP alle namhaften Unixfirmen,
ausser SCO ;), damit die kommerziellen Softwarefirmen die bisher
für X Entwickelten kapieren "Aha die sind auch dabei dann wird
es ernst".
5. In C++ sehe ich heute kein Problem mehr da der gnu compiler
auf allen wichtigen Platformen vorhanden ist. Auch ist er
relativ weit was den Standard anbelangt. Man kann sich auch
vorher überlegen welche Features der Sprache man nutzt und
welche nicht wie das viele andere Projekte auch machen, dann
geht man potentiellen Fallstricken gleich aus dem Weg.
Allerdings hat der Typ nicht viel Ahnung von C++, wenn da mal
die richtigen Leute mitmachen dann wird er das auch einsehen
dass seine Vorbehalte eher auf Unkenntniss aufbauen.
Mal sollte sich vielleicht auch mal die anderen Projekte anschauen
und analysieren warum die alle bisher gescheitert sind und daraus
lernen, sonst wird das wieder ein Projekt für den Papierkorb.
Für DirectFB gabs sogar ein angepasstes GTK und einige Karten wurden sogar accelerated unterstützt. Was hats gebracht? Nix.
Genau an diesem Problem wird auch "Y" scheitern, es sei denn man hat ein Konzept wie man das mit den Treibern lösen will. Ohne Treiber für die meisten modernen Karten wird es auch keinen X-Ersatz geben.
Gegenüber kommerziellen X-Servern kann sicher einiges getan werden. Also die Render-Extension war nie schnell, um Schriften zu rendern, da läuft der von xig.com Kreise um XF86. Treiber müssen einfach zu basteln sein und schnell released werden können. Die Y-Spezifikation hört sich gut an und lässt auch weiterhin Windowmanager neben den beiden grossen DEs zu, die müssen nur ein wenig angepasst werden. Ich will keinen Einheitsdesktop und mir passt der Mix aus GTK2 und QT3 sehr gut, schöne Vielfalt und keine Langeweile.
Wenn dann noch der Bandbreitenverbrauch im Netzwerk durch ein neues Protokoll gedrückt werden kann, umso besser. Also Fonts AA, sonstiges AA und AF, dazu genaue Shader (statt z.B. derzeit subpixel accuracy der nVIDIA quadro) in CAD-Beleuchtungsmodellen, die Anforderungen sind hoch und während ein X11 wahrscheinlich nach und nach zurechtgerückt wurde, kann man mit Berücksichtigung der neuen Technologien ganz von vorn anfangen. So sieht doch Fortschritt aus. Man muss nicht sofort migrieren, aber ich bin gern weit vorn mit dabei
Ein Term (modifiziertes iterm, die header der libiterm müssen separat installiert werden), eine einfache Uhr und ein einfachster Kalkulator gibts schonmal als Beispiel.
Die müssen vom Prinzip erstmal etwas vergleichbares wie GTK aufbauen, was dann aber direkt im Server und nicht beim Klienten läuft. Alleine das ist schon mal keine Kleinigkeit. Die Performance ist auch nicht so der Renner. Der XServer von Freedesktop erscheint mir performanter.
Da haben die Jungs sich ja was vorgenommen. Na mal gucken wie der Zuspruch ist und vor allem wieviele Leute die finden die an dem Projekt mitmachen. Mit 2-3 Leuten wird das nämlich nix werden, es sei denn sie sind alle Arbeitslos und können sich 12h täglich dem Projekt widmen ;)
while(1)
{
std::string name=generate_x_successor().name();
pro_linux.post_news_stream()<<name<<" loest XWindows ab"<<news::post;
current_proccess()->sleep(some_time());
}
An ablösen von X-Window denkt nun wirklich auch keiner, wenn man den aktuellen Status des Projektes sieht. Einige Designmerkmale sprechen eher stark dafür das es das Projekt nicht lange geben wird oder so vor sich hindümpelt wie Fresco.
Sicher hat Mark Thomas recht, daß die Codebasis von X11 in einem schlimmen Zustand ist. Aber einen neuen Server zu schreiben, ist nur der Anfang. Wer schreibt alle Clients um?
Ebend. Nicht machbar, zumal auch nicht wirklich ein Grund besteht. Es gibt Treiber für nahezu alle Karten unter X11, es kann gezockt werden und die normalen Anwendungen laufen recht performant. Sinnvoller scheinen wirklich Forks zu sein, die im inneren von X11 aufräumen und nach aussen (Xlib) unverändert bleiben.
so sehe ich das auch. Ein Anfang ist gut, aber es gab da schon einige Anfänge. Und jeder Ansatz der nicht 100% perfekt mit KDE und GNOME läuft, hat 0 Chancen unter Linux.
Ein eigenes Toolkit? Schonwieder? Ne, also das lässt er mal besser bleiben ;)
Zumal Linux mit GTK und QT bereits nurnoch 2 wichtige Toolkits hat, die sich inzwischen auch stark anhähern.
Wobei ein sauberes X schon etwas schönes wäre. Aber so ein Radikalschnitt, ich glaube nicht das soetwas uns weiterbringt. Dafür haben zu wenig Leute interesse an der Arbeit auf dieser Schicht, als das sich genug Leute finden würden die es auch über Jahre vorranbringen :/
Dann kann man sich in aller Ruhe hinsetzen und ne richtig feine Widget-Library in den Server packen. Dazu noch eine eine feines Toolkit und paar Beispielportierungen. Wenn das wirklich gut aussieht werden die Maintainer schon auf den Zug aufspringen.