Der Shuttleworth weiß auch nicht was er will, oder wird KDE jetzt zum St. Ubuntu Desktop. Zwei Projekte zu unterstützen ist einfach Kontraproduktiv. Fakt ist einfach es muss irgendwann einheit aufm Linux Desktop geben sonst wird sich nie irgend ein Linux Desktop durchsetzen. Egal ob Gnome, KDE oder FluxBox. Und jetzt kommt noch mit Integration das funktioniert einfach nicht, das hat die Vergangenheit mehr als deutlich gezeigt!
Finde ich nicht. Eher das Gegenteil ist der Fall. Aufgrund der Konkurrenzsituation versuchen sich KDE und GNOME gegenseitig zu übertrumpfen. Das kann für den Endnutzer nur gut sein.
Übrigens: GNOME Programme laufen ohne Problem auf KDE und umgekehrt.
Jep du hast schon recht mein erstes posting war etwas übertrieben, was ich mit Integration meinte ist das eine Anwendung immer fremden Desktop Unmengen Speicher braucht und natürlich auch langsam ist.
Du weißt einfach nicht was Shuttlewort will. Was du als Kontraproduktiv bezeichnest, dient einfach der "Artenvielfalt". Fakt ist nur eins und wirklich nur dies "Wir müssen sterben und die Pizza kommt vom Pizzaman!". Warum muß sich eine Desktopumgebung durchsetzen, gerade die Möglichkeit der Vielfalt spricht für Linux.
Von Anonymous Coward am Mo, 16. Oktober 2006 um 13:30 #
Sehr oft spricht die Vielfalt eben gerade gegen Linux. Objektiv gesehen ist Qt einfach besser als GTK - Umfangreicher, schneller, mächtiger (Signals/Slots können mehr als libsigc++), super dokumentiert - dennoch verwendet GNOME nach wie vor GTK! Ähnlich ist es bei dcop vs. Corba gewesen (das hat sich dank dbus nun zum Glück erledigt) oder bei den kioslaves - objektiv gibt es keinen Grund für GNOME, kioslaves nicht zu verwenden, trotzdem tun sie es nicht! Auswahl ist schön und gut, aber doch bitte schön da, wo es wichtig ist! KDE und GNOME haben ihre Daseinsberechtigung - wo GTK die hernehmen will (abgesehen von der Lizenz, die Kommerz-freundlicher ist - eigentlich eher ein Grund dagegen) ist mir schleierhaft.
mächtiger != besser Man sollte vielleicht daran denken das es hier nicht nur um Desktops sondern auch um Plattformen geht, Stichwort: Qtopia oder gtk-DirectFB, Toolkits sind nicht nur für Linux da sondern auch für andere Plattformen, darunter auch Mobiltelefone. XFCE ist auch ein sehr guter Desktop und hat noch viel weniger Funktionen als Gnome oder KDE. Der Satz "objektiv gibt es keinen Grund für GNOME, kioslaves nicht zu verwenden" ist außerdem bestenfalls belustigend, erstens ist gnome in C geschrieben und verwendet die gobjects während KDE auf C++ und qt setzt. Bis der Code von kioslaves nach gnome portiert ist, könnte man gnome-vfs gleich komplett neuschreiben.
Von Kevin Krammer am Mo, 16. Oktober 2006 um 18:20 #
Bis der Code von kioslaves nach gnome portiert ist
Er schrieb verwenden, nicht portieren. Um KIO Slaves zu verwenden muß man sie nicht portieren.
Und in welcher Sprache die Anwendung geschrieben ist, spielt keine Rolle, die IO Slaves sind schließlich eigenen Prozesse und das Protokoll zur Kommunikation läßt sich vermutlich in jeder Sprache implementieren, die einen Unix Socket öffnen kann.
Sämtliche KDE-Basisroutinen und -Libs sind LGPL oder teilweise sogar BSD-lizensiert. Und das war schon immer so, seit den KDE-1-Tagen. Unglaublich aber wahr.
Unsinn, man kann nicht einfach C++ code in der C-Programmen verwenden immerhin unterstützt die glib2 ja auch erheblich mehr Plattformen als KDE schon mal deshalb könnte man den Code nicht so ohne weiteres einbinden. Sinniger ist allerdings die kioslaves über FUSE zu laden anstatt eine gnome-vfs-modul-interface dafürzu schreiben.
Von Kevin Krammer am Mo, 16. Oktober 2006 um 21:39 #
Unsinn, man kann nicht einfach C++ code in der C-Programmen verwenden
Was du nicht sagst, hat aber bei der Benutzung von KIO-Slaves keine Bedeutung, weil der IO Slave schließlich nicht Teil des benutzenden Programms ist, sondern, wie ich schon im vorherigen Posting geschrieben habe, ein eigener Prozess ist, mit dem die Anwendung über einen Unix Domain Socket kommuniziert.
Es ist für einen Webbrowser schließlich auch egal, in welcher Sprache der Webserver geschrieben ist, die Daten werden über ein sprachneutrales Protokoll ausgetauscht.
Aber natürlich bleibt es jedem selbst überlassen, derartige Zusammenhänge zu ignorieren und lieber andere, in sich korrekte aber hier völlig deplatzierte, Zusammenhänge anzuführen.
>Es ist für einen Webbrowser schließlich auch egal, in welcher Sprache der Webserver geschrieben ist, die >Daten werden über ein sprachneutrales Protokoll ausgetauscht. Der Vergleich ist natürlich Unsinn, den gnome-vfs hat keinen "Browser" mit dem es sich über ein protokoll austauschen mit dem IO-Slave austauschen könnte. Außerdem müsste dann ja immer noch der IO/Slave mitsamt allen kde-libs im Hintergrund laufen. Würde also die Portabilität von Gnome auf KDE-Plattformen beschränken.
Von Kevin Krammer am Di, 17. Oktober 2006 um 12:20 #
Es ging schließlich um das nicht linken müssen bzw. die Sprachunabhängigkeit der KIO Kommunikation.
Man kann also jederzeit ein GNOME-VFS Modul mit KIO als Backend schreiben, ohne irgendwelche C/C++ Komplikationen als notdüftig konstruierte Ausrede zu benutzen.
Das dieses Modul logischerweise nur bei vorhandenem KDE Sinn macht, ändert nichts an der Portabilität von GNOME-VFS, denn schließlich sind dessen Module auch dynamisch ladbar. Umgekehrt kann man natürlich auch einen KIO Slave machen, der GNOME-VFS als Transport benutzt, auch wieder ohne irgendwelche Inkompatibilitäten als Ausrede vorschieben zu müssen.
Von Anonymous Coward am Mo, 16. Oktober 2006 um 18:07 #
moc (der C++-Präprozessor von Qt) generiert sog. Meta-Objekte, welche die Möglichkeiten zur Reflektion (Introspektion) erheblich erweitern. Dadurch kann man z. B. zur Laufzeit abfragen, welche Signale und Slots ein Objekt bereitstellt, ohne sich groß um den Typ dieses Objekts kümmern zu müssen. Lies am besten mal folgendes: http://doc.trolltech.com/4.2/templates.html Speziell die Sektion "GUIs are Dynamic"
bzw. bei defintion von QT_NO_KEYWORDS (seit Qt-4.1)
- Q_SLOTS - Q_SIGNALS
und schaut sich die darunter stehenden Funktionen (Rückgabewert void!) an. Dann schreibt moc eine .moc Datei, die die Signaturen als c-string enthält, z.B.:
Zur Laufzeit werden dann c-strings miteinander verglichen und die entsprechenden Funktionen aufgerufen. Wählt man jedoch einen Slot oder Signal das gar nicht existiert, so wird der Compiler anstandslos seine Arbeit verrichten. Erst zur Laufzeit gibt Qt eine Fehlermeldung wie
Object::connect: No such slot LCDRange::value_changed_(int)
aus.
Bei sigc++ überprüft der Compiler ob die Signatur der Slots und Signale.
Ich persönlich lasse mir gerne vom Compiler auf Verwechselungen und Tippfehler hinweisen ;)
1. Jegliche Rückgabewerte sing möglich, nicht nur void 2. erlaubt das Meta-system zudem die Manipulation (neue hinzufügen, vorhandene entfernen oder abändern) von signalen, slots und sogar kompletten Objekten zur Laufzeit. 3. ist auch das kurzfristige blocken, umlenken, mappen oder manipulieren von signals+slots kein Problem.
Also viele C++ Gurus finden Qt mit moc einfach zum kotzen und libsigc++ einfach die wesentlich eleganterere loesung. Und was an DCOP besser sein soll als an CORBA,was ja durchaus keine gnome erfindung ist,ist mir auch schleierhaft. Ich persoenlich finde Qt zum kotzen,gross,aufgeblasen,und irgendwie immer den drang alles selber machen zu wollen,vom XML parser bis zur DB Anbindung. GTK ist ein UI Toolkit,Qt ein Monster...
> Also viele C++ Gurus finden Qt mit moc einfach zum kotzen und libsigc++ einfach die > wesentlich eleganterere loesung
Was irgendwelche "C++-Gurus" denken, interessiert mich nicht, die durchschnittliche C++-API ist nicht gerade sehr elegant und lesbar. Der einzige Grund für libsigc++ mag sein, dass zur Kompilierzeit geprüft wird, ob signal und slot zueinanderpassen.
Der moc nimmt einem Arbeit ab, indem er (sauberen) Code generiert und erlaubt es mir, meinen eigenen Code eleganter und besser lesbar zu gestalten. Also wo ist das Problem?
> Und was an DCOP besser sein soll als an CORBA,was ja durchaus keine gnome erfindung > ist,ist mir auch schleierhaft.
CORBA ist vollkommen overengineered und zu komplex für den Desktop. Die Komplexität hätte die Verbreitung in den Anwendungen stark behindert (dass fast jede KDE-Anwendung über DCOP bzw. bald DBUS ansprechbar ist, hätte es mit CORBA wohl nicht gegeben). Das hörte sich 1998 vielleicht noch toll an, aber heute kräht da kein Hahn mehr nach, zumindest nicht auf dem Desktop. Warum wohl ersetzt Gnome sein CORBA-Krempel durch das wesentlich elegantere DBUS, das auch noch sehr ähnlich zu DCOP ist? Neben der unnötigen Komplexität für die Entwickler war damals der wesentliche Grund für DCOP die unzureichende Geschwindigkeit und der hohe Ressourcenverbrauch von CORBA.
> Ich persoenlich finde Qt zum kotzen,gross,aufgeblasen,und irgendwie immer den drang > alles selber machen zu wollen,vom XML parser bis zur DB Anbindung.
Qt4 ist modular (QtCore, QtGui, QtSql, QtXml), niemand zwingt dich, alle Module zuverwenden. Wenn man es aber doch tut, hat man eine gute designte API (was man nicht von allen anderen der alternativen APIs behaupten kann), die auf allen von Qt unterstützten Plattformen zur Verfügung steht. Warum soll ich für ein paar kleinere Xml-Dateien die ich parsen will mit libxml2 abplagen, wenn ich mit QtXml eine wesentlich elegantere API gleich mitgeliefert bekomme?
ja ich finde mydetector.signal_detected.connect( sigc::ptr_fun(warn_people) ); schoener als connect( mydetector, SIGNAL(detected()), this, SLOT(warnPeople()) );. und wer die template syntax nicht mag ist bei c++ eh falsch,ohne die dinger machts kein spass mehr ;-)
Was ist mit den gnome anwendungen? sind die ueber corba ansprechbar? ohne orbit geht ja bei gnome nix,lass mich aber gerne belehren.
Naja DBUS hoert sich am anfang ganz toll an,aber ich frage mich ob es auch das abdeckt woran man erst in 3-4 jahren denkt,oder ob man es da erweitern werden muss. Kann man ueber DBUS netzwerktransparent arbeiten?
wenn es sauber modularisiert ist,find ich das gut. btw speziell ueber qtxml habe ich aber auch schon einiges schlechtes gehoert,vorallem das es langsam sein soll...
DBUS ist laut Eigendefinition für den Desktop da nicht fürs Netzwerk und nach dem Vorbild von DCOP designt. Und trotz dass DCOP nicht netzwerktransparent ist, ist Netzwerktransparenz *die* Stärke von KDE. Es gibt keinen anderen Desktop, weder proprietär noch frei, der auch nur annähernd in diesem Bereich mit KDE mithalten kann (und Plan-9 fehlt der Desktop ;).
Es geht also weniger um theoretische Möglichkeiten, sondern um praktische Umsetzungen. CORBA/Orbit mag zwar netzwerktransparent sein, aber wieviele Gnomeprogramme nutzen Orbit in dem Maße wie KDE-Programme DCOP nutzen? KDE's Philosophie ist Pragmatismus und praktische Umsetzung von Lösungen im großen Stil und nicht die reine Lehre.
Das QT/Moc-Signal/Slots-Dingens ist meines Wissens wesentlich älter als analoge Konzepte in anderen Libs. Man sollte also Qt/Trolltech nicht vorwerfen, dass sie die ersten waren.
DCOP baut doch auf ICE auf,was wiederum netzwerktransparent ist? Hmm dann bin ich als theoretischer Informatiker bei KDE wohl einfach falsch...mir erscheint dbus jedenfalls mehr hingeschustert nach dem was man gerade braucht,als wirklich von grundauf durchdacht und geplant und funktioniert-fass-nie-wieder-an,also weit weg von der reinen Lehre. Ich hab keine ahnung in wieweit DCOP oder CORBA genutzt werden,ist das denn wichtig wenn man ueber deren maechtigkeit redet? ;-) Ja klar in Qt sind manche dinge historisch so,aber muss man deswegen dabei bleiben?
Naja zwischen netzwerkfähig und netzwerkfähig liegen Welten DCOP ist halt in der Hinsicht netzwerkfähig, dass es sich wegen der libICE mit seinem X-Server verbinden kann und darüber dann schon was netzwerktechnisch geht. Aber es kann sich nicht mit Anwendung Foo auf Server Bar unterhalten und schon garnicht ohne X11. Dazu ist es nicht gedacht und dazu gibt es meines Erachtens für in der Praxis relevante Probleme bessere Lösungen wie bspw. KIO (ja ich kenne FUSE ;-). Gleiches gilt für DBUS mit dem großen Vorteil dass DBUS nicht mehr nur auf X11-Programme beschränkt ist. Vor allem lokale Kommunikation zwischen Daemons (bspw. der ebenfalls neue HAL) und GUI-Anwendungen ist der große Vorteil von DBUS gegenüber DCOP und das was momentan wirklich dringend benötigt wird. DBUS geht zwar momentan nicht sinnvoll über Netzwerke, man hält sich aber die Hintertür offen, dass es durchaus in künftigen Versionen (ohne Inkompatibilitäten) möglich sein soll.
DCOP wird von jedem KDE-Programm genutzt (die meisten sehr ausgiebig). CORBA/Orbit unter Gnome hingegen nur recht wenig. Mächtigkeit allein reicht nicht aus, eine Lösung muss dem normalem Programmierer auch als das Natürlichste auf der Welt erscheinen, sonst nutzt er es niemals in großem Stil. Und DCOP und nun das nach seinem Vorbild geschaffene DBUS scheinen genau dieser Erwartung zu entsprechen.
Naja Qt hat mit jedem neuen Major Release die Codekompatibilität gebrochen insofern kann sich viel ändern. Der Grund für das Festhalten an den lange existierenden Eigengewächsen bei Qt ist auch: Es muss auf einigen vielen Nicht-(Standard-)-Unixplattformen laufen. Und da sich sehr auf Libs von anderen verlassen, die dann dort nicht laufen, man in speziellen Versionen plötzlich selbst pflegen muss oder sich plötzlich ändern ist da natürlich ein ziemliches Problem.
> [DBUS] mir erscheint dbus jedenfalls mehr > hingeschustert
Ja? Und in welcher Weise?
> Ich hab keine ahnung in wieweit DCOP oder > CORBA genutzt werden,ist das denn wichtig > wenn man ueber deren maechtigkeit redet?
Unnötig komplexe Lösungen bedeuten mehr Einarbeitungsaufwand für die Entwickler, daher geringere Nutzung. Ein RPC-Mechanismus, den kaum jemand nutzt, ist wertlos. Ein OSS-Entwickler kauft sich kein dickes Buch über RPC-Framework X, nur um seiner Anwendung 5 RPC-Methoden hinzuzufügen. SAP kann seine Mitarbeiter auf Schulungen schicken und die werden gut dafür bezahlt, sich mit SAPs Monster-Architekturen zu beschäftigen. Im OSS-Bereich benötigt man eher "Instant Gratification", erste Schritte sollten einfach sein, damit der Entwickler (die meisten verwenden ja ihre kostbare Freizeit darauf) nicht das Interesse verliert.
Ein weiterer Grund für DCOP statt CORBA war außerdem die geringe Performance von CORBA:
"However, after a year of attempting to make heavy use of CORBA in KDE, we have realized that it is a bit slow and memory intensive for simple use. It also has no authentication available."
Von Kevin Krammer am Mo, 16. Oktober 2006 um 21:45 #
Kann man ueber DBUS netzwerktransparent arbeiten?
Das ist durchaus im Bereich des möglichen, denn die D-Bus API abstrahiert die Art der Übertragung. Selbst eine Applikation, die entgegen allen Empfehlungen keine Bindings sondern die Basis API benutzt, sieht nur D-Bus Messages.
Möglicherweise ist die D-Bus Implementierung unter Windows sogar loopback/TCP basiert, ich bin da nicht ganz auf dem Laufenden. Derzeitiger Defaulttransport unter Unix sind Unix Domain Sockets, das ist nicht nur schneller, sondern hat auch Vorteile bei der Authentifizierung, usw.
> ohne orbit geht ja bei gnome nix,lass mich aber gerne belehren.
Richtig breit durchgesetzt hat sich das bei Gnome nie, wenn man es mit DCOP unter KDE vergleicht. Und jetzt bewegen sie sich ja in Richtung DBUS.
> aber ich frage mich ob es auch das abdeckt woran man erst in 3-4 jahren denkt
Woran man in 3-4 Jahren denkt wird man erst in 3-4 Jahren wissen. Alle Fälle gleich mit einbauen zu wollen, weil man sie ja irgendwann mal gebrauchen _könnte_, führt nur zu ineffizienten und over-engineered Lösungen. Dann hat man ein komplexes Monster, das keiner so richtig versteht und deshalb auch die meisten nicht in ihre Software integrieren. Man kann nicht mehr machen, als modular genug zu designen, so dass man das Konzept später entsprechend erweitern kann.
> naja das ist ja eben die kunst,konzepte zu entwickeln die einfach und zugleich > maechtig sind..
Ja, genau das, was CORBA nicht ist. Open Source-Projekte wie KDE arbeiten eher iterativ, d.h. man schaut erstmal darauf, was man wirklich zur Lösung der aktuellen Probleme braucht, implementiert es, und achtet darauf, dass es Erweiterungen erlaubt. Man baut nicht prophylaktisch irgendwelche Funktionalität ein, die _vielleicht_ mal jemand benötigen könnte. Dabei liegt der Schwerpunkt von DCOP/DBUS auf dem Desktop, und eben nicht in großen verteilten Anwendungen.
Von Kevin Krammer am Mo, 16. Oktober 2006 um 18:25 #
so viele C++ Gurus finden Qt mit moc einfach zum kotzen und libsigc++ einfach die wesentlich eleganterere loesung
Abgesehen davon, daß der moc auch Code für Introspection generiert, sind die beiden Signallösungen ohnehin nicht vergleichbar, weil sig++ die Verbindung zu Compilezeit auflöst, aber Qt zur Laufzeit. Beides hat seine Vor- und Nachteile.
irgendwie immer den drang alles selber machen zu wollen,vom XML parser bis zur DB Anbindug
Diesen Drang nennt man Kundenwunsch :) Ein Application development framework muß auf allen Plattformen die es unterstützt, die Basisfunktionalität heutiger Programme abdecken, d.h. GUI, Dateizugriff, XML, Netzwerk, Datenbank.
Mit GTK+ läßt sich das nur bedingt vergleichen, das es, wie du schon selber geschrieben hast, ein UI Toolkit ist.
Von Anonymous Coward am Mo, 16. Oktober 2006 um 18:36 #
Ähm, Du findest Qt "aufgeblasen" und CORBA toll? Entscheid dich mal... dcop ist angemessen (bzw. wird angemessen gewesen sein), CORBA ist für einen Desktop hoffnungsloser Overkill.
Nein: Die Vergangenheit hat gezeigt, dass das wunderbar funktioniert! Immer diese Versuche zur Gleichmacherei...
Tatsache ist doch, dass die meisten Gnome- und KDE-Nutzer nur ungern den Desktop wechseln. Du kannst gerne eine Einheits-Distribution machen, aber wenn dort kein KDE unterstützt wird, werden ich und viele andere sie nicht nutzen. Shuttleworth und (K)Ubuntu machen das schon ganz richtig. Warum, glaubst Du, ist das zur Zeit die angesagteste Distribution? Das hat auch damit zu tun, dass KDE und Gnome beide hervorrragend unterstützt werden.
Linux ist nicht trotz der verschiedenen Optionen so erfolgreich, sondern gerade wegen!
Ich sehe kein Problem in 2 großen Unix-Desktopumgebungen. So gibt es dann eben 2 große freie Desktopumgebungen (KDE u. Gnome) und 2 gr0ße unfreie (Windows u. Mac OS - bzw. deren GUI).
und ausserdem muss sich auch bald entscheiden ob nun Ketchup oder Mayo auf die Pommes gehört. Ist doch kontraproduktiv zwei Tuben an der Pommesbude stehen zu haben....
Stimmt: zwei komplette Desktopumgebungen zu entwicklen, ist völlig sinnlos. Die von KDE und GNOME gepflegten Kleinstunterschiede bieten allenfalls subjektive Vorteile, stiften nur Inkompatibilitäten, und verwirren die breite Masse.
Allerdings ist Linux gegenwärtig noch eine Art Asylheim für Flüchtlinge und Vertriebene, die ihre ursprünglichen Systeme mehr oder weniger durch die Dominanz von WindowsXP verloren haben -- da ist erstmal kulturelle Vielfalt angesagt, weil jeder etwas anderes gewohnt ist.
Irgendwann werden sich die Leute aber fragen, warum sie sich mit GNOME beschäftigen sollten, wenn es KDE gibt, und andersherum: Der durchschnittliche Apache-Anwender fragt auch selten nach Alternativen zu Apache. Und wäre Photoshop kostenlos erhältlich, würde auch niemand nach The GIMP fragen.
Zwischendrin wird es noch einige geben, die fragen, welche Teile von GNOME und welche Teile von KDE Sinn machen, und sie werden versuchen, beides zu kombinieren. Man sieht es ja jetzt schon an Experimenten wie Dolphin, der Konzepte von Nautilus stärker gewichtet und viele Fähigkeiten des Konquerers weglässt.
Von daher ist Warten angesagt, bis eine der Desktop-Umgebungen in einem bestimmten Sprachraum schlicht ausstirbt. Fans und Entwickler haben bezüglich ihrer Software nunmal keinen Abstand und überbewerten jeden minimalen Unterschied der Bedienung masslos. Alle anderen aber werden sich an das einzige objektives Kritierium halten: ob eine Desktop-Umgebung von den meisten anderen Menschen in ihrer sozialen System auch benutzt wird.
Also macht das Verhalten von Shuttleworth schon Sinn: Er orientiert sich an der gegenwärtigen Nachfrage des Geek-Publikums und legt seine Eier nicht alle in einen Korb.
KDE und Gnome haben zwei komplett unterschiedliche DE Konzepte weswegen weder das eine noch das andere sich pauschal durchsetzen kann. Im US Raum fragt kein Mensch nach KDE und in Europa ist KDE nach einigen Meinungen Platzhirsch. Da beide Projekte aber international sind wird es immer beide Projekte geben.
Btw. Es fragen viele Apache Anwender die ich kenne nach Alternativen, und ich kenne auch einige die ich ohne zögern einem Apachen vorziehen würde.
Wenn Du GNOME und KDE als "zwei komplett unterschiedliche DE Konzepte" bezeichnet, sagst Du nur, dass Du ein Geek bist. Der Normalanwender kann darin wahrscheinlich nur wenig mehr Unterschiede erkennen, als ein Geek bei zwei Kühen, die irgendwo auf der Weide stehen. Ein Bauer oder Züchter wird sofort all die unterschiedlichen Details, die aus seiner Sicht relevanten Vor- und Nachteile erkennen, und den Geek auslachen. Aber ein Nicht-Landwirt?
In diesem Zusammenhang: Die drei Topgründe, KDE zu benutzen! Mal ehrlich: Die sind für die 90% der Anwedner subjektiv oder bedeutungslos -- also für den Büroangestellten oder die Hausfrau zu Hause.
Auch sehr schön an diesem Blogpost: Der offensichliche Mangel an Ahnung! Da ist also schon ein Geek, der ein Blog hat, und sich auch noch über die Desktop äußert, aber trotzdem hat er nicht herausbekommen, daß die Funktion "Open in Terminal" für Nautilus in eine seperaten Paket untergebracht ist, dass man nachinstallieren muß. Lustig auch, daß in den Kommentare sich promt ein zweiter Geek als ebenso planlos outet, und seine eigene geschrieben Lösung promotet!
Wäre ich ein Geek, müßte ich jetzt wohl schrieben, was für Trottel das sein müssen: Sie konnten offensichtlich nicht mal mit Google umgehen. Aber objektiv betrachtet fehlte ihnen wohl nur die Zeit, auch nur einen zweiten Desktop hinreichend gut kennenzulernen!
Und wenn das schon einem Geek passiert, wie sollten sich 90% der übrigen Desktop-Anwender damit auseinandersetzten können? Insofern entspringt deine Äußerung wohl eher Wunschdenken.
Übrigens: Auch Du machst den typischen Fehler und verwechselst Existenz mit Relevanz! Enlightment existiert nach wie vor, nur ist es für den Desktop nicht relevant. Wenn ich von Aussterben spreche, meine ich Relevanz. Natürlich wird es beide DEs immer geben: Der Windowmanager Sawfish existiert auch noch, aber relevant ist er nicht (mehr).
> [...] sagst Du nur, dass Du ein Geek bist *lach*
> Der Normalanwender kann darin wahrscheinlich nur wenig mehr Unterschiede erkennen [...] So geht es mir, wenn ich die Abdeckung meines Fernsehgerätes öffne. Was sagt das über die Relevanz der Argumente der Entwickler aus? Das ein Normalanwender bei Benutzung entsprechender Distributionen keinen Unterschied in der Benutzung (mehr) bemerkt, liegt an den Bemühungen vieler Entwickler, einheitliche und wiedererkennbare Elemente in der Gestaltung zu verwenden. Das allein ist aber noch lange kein Grund dafür, das GNOME oder KDE irrelevant sind.
> Mal ehrlich: Die sind für die 90% der Anwedner subjektiv oder bedeutungslos Ehrlich ja, richtig nein. Ohne Entwickler keine Software, ohne Software kein Angebot für die Benutzer. Nicht jeder Qt/KDE-Entwickler hätte seine Anwendung unter Gtk/GNOME geschrieben - und umgekehrt. Warum wohl? Weil sich für verschiedene Anforderungen verschiedene Lösungswege anbieten, weil bei mehreren Lösungswegen persönliche Geschmäcker entscheiden und weil jeder Lösungsweg seine berechtigten Argumente besitzt.
> Wäre ich ein Geek, müßte ich jetzt wohl schrieben [...] Aber zum Glück bist Du kein Geek, Du bist einfach so der Größte. ;)
> Und wenn das schon einem Geek passiert, wie sollten sich 90% der übrigen Desktop-Anwender damit auseinandersetzten können? Man muss nicht jede Alternativlösung kennen, um eine bestimmte zu bevorzugen. Selbst wenn ich subjektive Gründe habe, auf meine Lieblingsdesktopenvumgebung zu setzen, was stört Dich das denn?
> Auch Du machst den typischen Fehler und verwechselst Existenz mit Relevanz! Und Du machst den typischen Fehler des Egomanen und verwechselst "Relevanz für mich" mit "Relevanz für die Allgemeinheit".
Ich muss jedesmal schmunzeln, wenn ich solche "lasst uns das doch verallgemeinern"-Diskussionen sehe. Unterstellt man mal, das die insgesamt chaotisch agierende Gemeinde freier Softwareentwickler den diversifizierten Wunsch der Entwickler und Anwender nach einer für sie maßgeschneiderten Lösung darstellt, so kommt man zu einer interessanten Beobachtung: Obwohl hier offensichtlich die globale, ordnende, "rationalisierende" Hand fehlt, gibt es an allen Ecken und Enden Standards, Normen, Zusammenarbeit. Ganz offensichtlich ist man also selbst unter diesen Bedingungen in der Lage, bei wirklich wichtigen Punkten an einem Strang zu ziehen. Vielleicht normiert man deshalb keine einheitliche Desktopumgebung, weil es keine reale Notwendigkeit dafür gibt?
Selbst wenn ich subjektive Gründe habe, auf meine Lieblingsdesktopenvumgebung zu setzen, was stört Dich das denn?
Du unterstellst mir eine Meinung, die ich nicht geäußert habe: Mir ist völlig gleich, was oder wie Du Deinen Computer benutzt. Das immer wiederkehrende Entwickler-Argument -- "wir machen, was wir wollen" -- juckt mich ebensowenig: Wenn irgendjemand meint, seine Zeit mit der Entwicklung von Enlightment oder ähnlichem zu verbringen, ist das sein Bier.
Auch Deine Unterstellung, ich würde mir eine einzige Desktop-Umgebung wünschen, zeigt nur, daß Du derjenige bist, der sich von Vorurteilen leiten läßt: Ich habe nicht geschrieben, es sollte nur eine Desktop-Umgebung geben. Ich sagte, es wird irgendwann nur noch eine relevant sein.
Wenn Du also demnächst jemandem unterstellst, ein Egomane zu sein, dann versuche zuerst, Dein Gegenüber zu verstehen. Danke.
Im übrigen ist das Argument, manche Entwickler hätten vielleicht bei einer einheitlichen Umgebung niemals etwas anderes programmiert, zwar zutreffend, aber leider unvollständig: Vielleicht gab es auch Entwickler, die sich durch den Mangel an Einheitlichkeit haben abschrecken lassen. Da die Menge der möglichen und tatsächlichen Beiträge dieser beiden Gruppen unbekannt ist, ist das Argument ziemlich schwach.
> Du unterstellst mir eine Meinung, die ich nicht geäußert habe: Mir ist völlig gleich, was oder wie Du Deinen Computer benutzt. Dann sieh bitte "ich" als "die anderen Anwender". Hoffe, mein Standpunkt wird dadurch klarer. Weder Du noch ich wissen vollständig, was Anwender brauchen. Deshalb sind Pauschalaussagen über den Sinn oder Unsinn von Softwareangebot und -nachfrage völlig falsch.
> Auch Deine Unterstellung, ich würde mir eine einzige Desktop-Umgebung wünschen, zeigt nur, daß Du > derjenige bist, der sich von Vorurteilen leiten läßt Nein, ich lasse mich von dem leiten, was ich von Dir gelesen habe. Darf ich zitieren? zwei komplette Desktopumgebungen zu entwicklen, ist völlig sinnlos
> Wenn Du also demnächst jemandem unterstellst, ein Egomane zu sein, dann versuche zuerst, > Dein Gegenüber zu verstehen. Danke. Wenn er sich klar ausdrückt, kann man ihn auch verstehen. Und noch etwas, erinnerst Du Dich noch? Wenn Du GNOME und KDE als "zwei komplett unterschiedliche DE Konzepte" bezeichnet, sagst Du nur, dass Du ein Geek bist. Nun spiele mal nicht die beleidigte Leberwurst, nur, weil Dir der Wind mal so entgegenpustet, wie Du es vorher mit Michael veranstaltet hast.
> Im übrigen ist das Argument [...] zwar zutreffend, aber leider unvollständig Richtig. Es mag sein, dass sich Jemand von der Diversifikation der Umgebungen abschrecken läßt. Ich versuchte auch lediglich klarzumachen, dass die Allgemeingültigkeit, die Deine Aussagen durch Formulierungen wie "es wird irgendwann nur noch eine relevant sein", "sind [...] subjektiv oder bedeutungslos" suggerieren, nicht gegeben ist. Dementsprechend schwach ist das, was Du eigentlich von Anfang an sagen wolltest.
Hm, seit wann ist "Geek" sein, eine negative Beurteilung? Ich hatte es eher als ironisch und humorvolle Eigenbeschreibung von Geeks interpretiert. Na ja, vielleicht lag ich damit falsch. Dann bitte ich Michael um Entschuldigung.
Ich gebe Dir auch gerne recht, dass Pauschalaussagen nach Softwareangebot und -nachfrage gefährlich sind. Vielleicht ist Dir ja aufgefallen, dass ich keine Aussage darüber gemacht habe, welche Desktop-Umgebung dominieren wird.
Es gibt aber historische Erfahrungen -- wie etwa die wachsende Dominanz von Photoshop oder beispielsweise die Tatsache, dass Firmen in Stellenanzeigen Erfahrungen mit spezieller Software verlangen --, die vermuten läßt, dass die Monopoltendenz im Software-Markt nicht nur auf Anbieterseite zu suchen ist, sondern auch ganz stark auf Nachfragerseite.
Insofern wage ich eine Prognose. Ich gebe gerne zu, dass sich diese in Zukunft als falsch erweisen kann.
>Der Normalanwender kann darin wahrscheinlich nur wenig mehr Unterschiede erkennen
Das ist eine Interessant Beobachtung die ich auch immer wieder mache. Ich habe in meinem Bekanntenkreis viele Windows Benutzer und 2 MacOS Benutzer. Alle sind keine "Geeks" sondern verwenden halt einen PC auf der Arbeit und surfen zu Hause etwas im Internet usw.
Ich habe KDE und GNOME installiert und wechsel auch ab und zu mal gerne. Wenn jetzt aber die anderen (win und MacOS Benutzer) bei mir sind und mir über die Schulter schauen oder auch mal kurz meinen PC benutzen, dann fällt denen weder auf, dass es gestern GNOME war und heute KDE ist noch das es etwas komplett anderes wie ihr windows oder MacOS ist. Ich kann es mir nicht erklären, aber irgendwie scheint für den "normalen" Anwender alles gleich zu sein.
Ich finde das nicht schwer nachzuvollziehen. Man muss nur an ein Gebiet denkt, dass einem selbst unbekannt ist: etwa Kühe, Leiterplatten, Briefmarken, Münzen, Rock'n'Roll Bands, Punk Bands, Heavy Metal Bands, Rapper, HipHoppern, klassischen Komponisten, bestimmten Stilrichtungen in der Malerei, Architektur, Literatur, etc.
Ich behaupte mal der durchschnittliche Leser auf Pro-Linux wird Schwierigkeiten haben, zwei Impressionisten auseinander zu halten, während eine Kunststudentin keinerlei Probleme damit hätte.
Oder betrachte es andersherum. Selbst wenn einer Deine Bekannten fragen sollte: "Sag mal, hast Du etwas geändert?" und Du dann antworten würdest: "Ja, ich habe ein paar Einstellungen verändert und ein neues Theme installiert", so wäre das wahrscheinlich eine ebenso plausibele Antwort für die wie: "Ja, das ist KDE und das vorher war GNOME."
>etwa Kühe, Leiterplatten, Briefmarken, Münzen, Rock'n'Roll Bands, Punk Bands, Heavy Metal Bands, Rapper, HipHoppern, klassischen Komponisten, bestimmten Stilrichtungen in der Malerei, Architektur, Literatur, etc.
Naja, ich kann vielleicht nicht die Band, den Rapper oder die Briefmarke genau klassizifieren oder sagen welche Briefmarke mehr Wert ist. Aber mir fallen doch trotzdem unterschiede auf, ob die gleiche Band von gestern auf der Bühne steht oder nicht und das sie vielleicht einen anderen Stil haben (härter, softer, etc.),...
Aber das man so garnichts am PC merkt verwundert mich schon immer wieder. Das zeigt imho aber auch das so sachen wie "Einheitlichkeit" total überschätzt sind, zumindest mit Blick auf den "normalen"-user. Die unterschiede z.B. zwischen einem GNOME und KDE Programm (egal ob jetzt beide unter GNOME oder unter KDE ausgeführt werden) werden den meisten "normalen" Anwendern wahrscheinlich nicht auffallen bzw. nicht stören. Das merkt man ja auch daran, dass sie zum Teil auch unter Windows Shareware/Freeware verwenden die zum Teil ganz andere UIs haben als die "professionelle" Software und groß gestört hat sich daran bisher noch niemand.
Du gehst von falschen Tatsachen aus. Deine Bekannten saßen nur kurz an Deinem PC und arbeiteten nur wenig. Der Unterschied wird umso deutlicher, je vertrauter man mit einer Sache wird.
> Das zeigt imho aber auch das so sachen > wie "Einheitlichkeit" total überschätzt > sind, zumindest mit Blick auf > den "normalen"-user.
Gerade "normale" Benutzer benötigen einheitliche Oberflächen, die sich möglichst gleich verhalten. Dann lernt man einmal und kann dann sein Wissen überall anwenden. Wenn jede Anwendung andere Konzepte und Begriffe für dieselbe Funktionalität verwendet, ist der Benutzer verwirrt. Dazu gibt es genug Untersuchungen im HCI-Bereich, z.B. zu Effektivität des Arbeitens je nachdem wie einheitlich Menü-Optionen etc. benannt sind.
In der Tat. Linspire, Xandros und Slackware um nur mal ein paar prominente US-Distri-Beispiele zu nennen sind alle mehr oder weniger KDE-zentriert. Ganz abgesehen davon kommen ein paar extrem produktive und aktive KDE-Gurus aus Nordamerika, z.B. Aaron Seigo (Kanada) und Erik Lafoon (USA)...
Von Assistent des Protokollfuehrer am Mo, 16. Oktober 2006 um 22:38 #
Für das Protokoll sollte angemerkt werden dass die Aufzählung (leider) schon fast vollständig ist (würde mich wundern wenn du mehr als ein Dutzend Namen von US-Amerikanern die aktiv an KDE arbeiten wüsstest). Aaron Seigo ist übrigends Kanadier.
Gibt noch ein paar. George Staikos ist meines Wissens US-Amerikaner und Waldo Bastian (auch wenn er Deutscher ist) ist in den USA. Es stimmt zwar schon, dass in Europa zahlenmäßig mehr KDE-Entwickler sitzen, nur ist es eben nicht so Schwarz-Weiß wie gerne behauptet wird. Was den Einfluss angelangt, behaupte ich, dass die nordamerikanischen KDE-Entwickler da proporzmäßig extrem gut abschneiden (und in grauer Vorzeit soll sogar mal ein Miguel von KDE angetan gewesen sein...).
Was man hingegen wohl als Tatsache verbuchen kann ist, dass Gnome von fast allen großen hauptsächlich auf den Servermarkt orientierten IT-Softwareanbietern favorisiert wird. Den Ausschlag werden wohl neben Zufällen (der Linux-Serversoftware-Shooting-Star Red Hat hatte halt Gnome und war als größter Linuxdistributor somit deren Vergleichsmaßstab Nummer 1) psychologische Gründe gewesen sein, wie dass man Gnome als traditioneller und konservativer und somit als "ernsthafter" empfand (C vs. C++ ). Und dann natürlich die Tatsache, dass KDE im Gegensatz zu Gnome eine komplett andere Beteiligung durch Firmen aufweist, die es für große Kapitalgesellschaften schwer macht dort die Richtung vorzugeben (und angesichts der Hühott-Bewegungen in Gnome möchte man meinen Gottseidank): An KDE beteiligen sich neben der allgemeinen Community hauptsächlich "personenfixierte" Unternehmen, wie mittelständige GmbHs (etliche Beispiele in Europa), Aktiengesellschaften in Mitarbeiterbesitz (insbesondere Trolltech) und selbst Suse hat in dieses Bild mentalitätsmäßig reingepasst (auch wenn sie durch Fremdkapital finanziert waren).
So Geschmarri wie an den Haaren herbeigezogene Lizenzprobleme und so hat da niemals die Firmen interessiert, das waren Ausflüchte.
> Waldo Bastian (auch wenn er Deutscher ist) ist in den USA. Er ist meines Wissens Niederländer. Zumindest wurde er laut People Behind KDE-Interview in den Niederlanden geboren.
> würde mich wundern wenn du mehr als ein Dutzend Namen von US-Amerikanern die aktiv an > KDE arbeiten wüsstest
Allen Winter (kdepim), Scott Wheeler (juk, taglib, wohnt allerdings in D), Ryan Nickell (Superkaramba/Plasma), Wade Olson (PR), Ian Monroe (Amarok), Celeste Paul (Usability), Ian Geiser (Core), Chris Lee, Matt Rogers (Kopete), Benjamin Meyer (aus den USA, jetzt bei Trolltech), George Staikos (Core), Gary Cramblitt (Accessibility), Eric Laffoon (Quanta, Kommander)
13! Reicht das fürs erste? Das sind alles recht aktive, zum Teil äußerst aktive Leute, auf http://worldwide.kde.org finden sich auch noch mehr. Zugegeben, in Europa ist der Teppich noch deutlich dichter.
So ein Schmarrn sagt man dazu bei uns im Bayernland. Dein Posting ist geprägt von einem tiefgreifendem Knick in der Optik... Monokultur ist nicht zwingend toll, ein solcher Funktionszusammenhang ist sogar eher die Ausnahme - aber das haben die Vorposter ja schon zur Genüge vertreten.
as dir aber auch völlig entgangen ist: Man sollte solche Vorschläge mal in aller Ruhe zu Ende denken, dann zeigen sich meist schon die dicksten Patzer im Ansatz... Die meisten Gnome- oder KDE-Entwickler arbeiten in erster Linie für sich selbst - nenn es ein Hobby, eine Berufung, was auch immer - klar ist nur eins: DIE sind niemand, die für DICH irgendwas tun sollten oder müssen. Denn du hast kein Geld bezahlt, höchst warscheinlich noch nichts nennenswertes beigetragen oder auch nur was gespendet. Und selbst dann hättest du kein Recht und keine Möglichkeit, von wildfremden Leuten zu fordern, sie mögen ihre Freizeit nach deinem Masterplan gestalten, um dann am Ende für dich die (Desktop)Welt zu beherrschen oder so. Was willst du tun - jeden nach Guantanamo schicken, der sich ein eigenes DE stricken möchte, weil er so viel Spaß dran hat? Programmiererlaubnis nur noch nach planwirtschaftlichen Kriterien vergeben?
Sorry für die harten Worte, aber ich selbst bin zufällig freizeitmäßig in solchen Fahrwassern tätig, und fühle mich von diesen quengligen Forderungen allmählich leicht verkohlt. Wir stellen phantastische Dinge auf die Beine, und ob sich irgendein Fuzzi von der Auswahl zwischen zwei unterschiedlichen Oberflächen überfordert/verwirrt fühlt, soll er da glücklich sein wo man keine Wahl bekommt. Ich mach das für mich und für die Leute mit ähnlichem Technologie-Geschmack, für niemand sonst.
Guidance wurde in Zusammenarbeit mit dem KDE-Usability-TEam entwickelt (und nicht speziell für Kubuntu) und gilt eigentlich als potentieller Ersatz für kcontrol. Und KControl als "alt bewährt" zu bezeichnen, naja. Es gilt selbst innerhalb der Community als stark verbesserungswürdig.
Das gut an dem Herrn ist das er bisher das gnome-projekt nicht mit seinen Ideen belästigt, nichts gegen ihn persönlich aber das was bei Ubuntu "gnome" heisst hat recht wenig mit dem gnome zu tun, welches man auf gnome.org findet.
So? Ich hab nen eingefleischten Ubuntu-Gnome-Nutzer mit dem Kontrollzentrum von Kubuntu mächtig beeindrucken können. Permament musste er irgendwelche kleinen Kontrollapplets für dies und das suchen, ich bin einfach mal das ganze Kontrollfeld durchgegangen und ich war angenehm davon überrascht wieviele Systemfunktionen man dort schön sortiert einstellen kann.
Ach ja kleiner Hinweis: Es schaut komplett anders aus als das des Standard-KDE-Desktops, falls du wider erwarten doch noch kein Kubuntu gesehen haben solltest...
Ob die Gconf-Registry da besser ist? Das standardmäßige KDE-Kontrollzentrum gehört verbessert keine Frage, aber nicht einfach beschnitten, das löst keine Usabilityprobleme. Und falls du es nicht nicht verglichen hast schau dir mal das Kontrollzentrum von KDE unter Suse (hauptsächlich KDE-Stanard) und unter Kubuntu (neue Struktur) an und du weißt was ich meine.
Und wozu sind Kontrollzentren da? Konfigurationsmodule zentral zu bündeln, damit man nicht an x verschiedenen Stellen mit x verschiedenen Tools rumbasteln muss.
Solange das KDE Projekt sich nich von seiner Kohle abhängig machen läßt ist das doch ne super sache so nen Multi Millionär als Finanzier im Rücken zu haben
Man denke nur an RedHats Bluecurve um ein gleiches Look'n Feel zu schaffen. EIgnetlich ein super ANsatz, man findet sich unter Kde und Gnome gleichermaßen durch das Theme (ist es überhaupt eines zurecht. Und wenn man Standard will einfach abschalten. Sowas genügt doch für den "Einheitsbrei".
Bluecurve schön und gut. Besser isses doch wenn man jede x-beliebige Skin des jeweils anderen Desktops direkt nutzen kann. Muss man nicht dauernd doppelte Arbeit machen und Einheitsbrei muss man auch nicht befürchten. Jeder stellt die Skin ein die er mag. Klingt nach Wunschenken und Zauberei? KDE tut genau das für Gnomeprogramme: Dank der qt-gtk-Theming-Engine jubelt es jedem x-beliebigen GTK-Programm seine jeweils eingestellte Skin unter (Ja man kanns zu allem Überfluss sogar im KDE-Kontrollzentrum konfigurieren, man kennt das ja von uns KDE-Nutzern ;-). Wieso gibts sowas eigentlich nicht umgekehrt?
Um KDE-Patron zu werden braucht man als Einzelperson bzw. Unternehmen mit weniger als 50 Angestellten nur 5000/Jahr bzw. als Unternehmen mit mehr als 50 Angestellten 10000/Jahr an das KDE-Projekt spenden. Dafür muss man also nicht unbedingt Multi-Millionär sein.
Die Kritik kam von einer Einzelperson und seinen Gefolgsleuten - 99% der deutschen Community hatte und hat keinerlei Probleme mit der Art wie Kubuntu entwickelt wird, und hatte auch nie Zweifel, das alles so läuft wie es läuft und keine Distribution besonders bevorzugt wird.
Übrigens ist mit Sebastien Bacher (seb128) auch nur ein Entwickler für Gnome abgestellt, die anderen arbeiten ihm zu. Bei KDE ist das mit Jonathan Ridell (ridell) ebenso genauso.
Mark meinte es einfach gut und hat nur das bekräftigt, was auch früher schon so galt. (Falls jemand fragt, woher ich meine Infos habe: Ich war persönlich im Gegensatz zu dem Herrn M., der das ganze eigentlich angezettelt hat, übrigens beim IRC-Meeting, wo dies mit Mark Shuttleworth besprochen wurde. Ist aber alles in den IRC-Logs nachzulesen.)
@pro-linux: Diese Infos sollten euch aber bereits auch zugetragen worden sein und ich dachte nicht das diese Falschmeldung nochmal auftaucht.
GNOME und KDE sind zwei besonders erflogreiche Projekt, die es geschafft haben eine "kritische Masse" an Entwicklern zu begeistern.
Jedoch sind viele Projekte und Forks eine ein-Mann-Shows, die mit bestehenden quelloffenen Lösungen nicht zufrieden sind und selbst ein neuen Versuch starten. Das ist sicherlich positiv für die Innovation falls es tatsächlich ein Problem mit der bestehenden Lösung gibt (siehe Mimix und Linux).
Doch bei vielen Projekten habe ich den Eindruck dass das Rad einfach neu erfunden wird und dass es zu einer Zersplitterung kommt. Deshalb haben wir viele "Halb-Lösungen" zu kommerziellen Software. Wäre es nicht besser wenn die Opensource Entwickler ihre Kräfte besser bündeln würden?
Ich trage selbst zu einem quelloffene Software Projekt (www.octave.org) bei und staune oft darüber wie viele alternative Projekte es gibt, die das selbe Ziel haben, nämlich das kommerzielle Programm Matlab nach zu bauen. Alle Projekte, die ich kenne sind jedoch immer noch ziemlich weit von diesem Ziel entfernt.
"Ich trage selbst zu einem quelloffene Software Projekt (www.octave.org) bei und staune oft darüber wie viele alternative Projekte es gibt, die das selbe Ziel haben, nämlich das kommerzielle Programm Matlab nach zu bauen." Da würde ich den Leuten vielleicht mal eine E-Mail schreiben und freundlich anfragen ob es da Möglichkeiten zur Kooperation gibt. Kommunikation ist schon was schönes, Gnome- und KDE-Entwickler reden ja zumeist auch miteinander.
Die Bündelung wie es sich manche vorstellen ist nicht immer ganz einfach, da manche Projekte zwar ähnliche aber nicht ganz gleiche Ziele haben. Allerdings wird auch öfter Zusammengearbeitet als man gemeinhin sieht. z.B. tauschen ReactOS und Wine Informationen und Codeteile aus.
Ganz abgesehen davon, daß sich die Aussage auch auf kommerzielle Software ausdehnen läßt (z.B. Paint Shop, Photoshop, PhotoImpact, ...) und sogar auf Implementierungsdetails (Opendocument vs MSOXML) oder auf Hardware.
> Ich trage selbst zu einem quelloffene Software Projekt (www.octave.org) bei [...] Das ist sehr lobenswert. Die Ingenieur- und wissenschaftlichen Anwendungen wie MATLAB, Origin, Labview, etc. sind in der OpsenSource-Szene leider viel zu unterrepräsentiert. Wo doch gerade diese Anwender offenen Standards positiv gegenüber stehen.
Und jetzt kommt noch mit Integration das funktioniert einfach nicht, das hat die Vergangenheit mehr als deutlich gezeigt!
Übrigens: GNOME Programme laufen ohne Problem auf KDE und umgekehrt.
Nein, was es nicht. Dein erstes Posting war *sehr* uebertrieben. ;)
Besonders die Stelle "Der Shuttleworth weiß auch nicht was er will"
hat mir gut gefallen.
Immerhin ich hab für Unterhaltung gesorgt, und die Ereignisse überschlagen sich!
bist wohl noch stolz drauf was ? ...
einfach der "Artenvielfalt". Fakt ist nur eins und wirklich nur dies "Wir müssen sterben und die
Pizza kommt vom Pizzaman!".
Warum muß sich eine Desktopumgebung durchsetzen, gerade die Möglichkeit der Vielfalt spricht für
Linux.
Küss die Hand
Man sollte vielleicht daran denken das es hier nicht nur um Desktops sondern auch um Plattformen geht, Stichwort: Qtopia oder gtk-DirectFB, Toolkits sind nicht nur für Linux da sondern auch für andere Plattformen, darunter auch Mobiltelefone. XFCE ist auch ein sehr guter Desktop und hat noch viel weniger Funktionen als Gnome oder KDE.
Der Satz "objektiv gibt es keinen Grund für GNOME, kioslaves nicht zu verwenden" ist außerdem bestenfalls belustigend, erstens ist gnome in C geschrieben und verwendet die gobjects während KDE auf C++ und qt setzt. Bis der Code von kioslaves nach gnome portiert ist, könnte man gnome-vfs gleich komplett neuschreiben.
Momentan arbeitet man ja an einem Ersatz, der direkt in glib integriert werden soll.
Er schrieb verwenden, nicht portieren. Um KIO Slaves zu verwenden muß man sie nicht portieren.
Und in welcher Sprache die Anwendung geschrieben ist, spielt keine Rolle, die IO Slaves sind schließlich eigenen Prozesse und das Protokoll zur Kommunikation läßt sich vermutlich in jeder Sprache implementieren, die einen Unix Socket öffnen kann.
Was du nicht sagst, hat aber bei der Benutzung von KIO-Slaves keine Bedeutung, weil der IO Slave schließlich nicht Teil des benutzenden Programms ist, sondern, wie ich schon im vorherigen Posting geschrieben habe, ein eigener Prozess ist, mit dem die Anwendung über einen Unix Domain Socket kommuniziert.
Es ist für einen Webbrowser schließlich auch egal, in welcher Sprache der Webserver geschrieben ist, die Daten werden über ein sprachneutrales Protokoll ausgetauscht.
Aber natürlich bleibt es jedem selbst überlassen, derartige Zusammenhänge zu ignorieren und lieber andere, in sich korrekte aber hier völlig deplatzierte, Zusammenhänge anzuführen.
Der Vergleich ist natürlich Unsinn, den gnome-vfs hat keinen "Browser" mit dem es sich über ein protokoll austauschen mit dem IO-Slave austauschen könnte. Außerdem müsste dann ja immer noch der IO/Slave mitsamt allen kde-libs im Hintergrund laufen. Würde also die Portabilität von Gnome auf KDE-Plattformen beschränken.
Man kann also jederzeit ein GNOME-VFS Modul mit KIO als Backend schreiben, ohne irgendwelche C/C++ Komplikationen als notdüftig konstruierte Ausrede zu benutzen.
Das dieses Modul logischerweise nur bei vorhandenem KDE Sinn macht, ändert nichts an der Portabilität von GNOME-VFS, denn schließlich sind dessen Module auch dynamisch ladbar.
Umgekehrt kann man natürlich auch einen KIO Slave machen, der GNOME-VFS als Transport benutzt, auch wieder ohne irgendwelche Inkompatibilitäten als Ausrede vorschieben zu müssen.
Da ich mich damit nicht so auskenne, würde es mich mal interresieren, was Qt da mehr kann als libsigc++?
Signals und Slots gibt ja bei beiden.
http://doc.trolltech.com/4.2/templates.html
Speziell die Sektion "GUIs are Dynamic"
- slots
- signals
bzw. bei defintion von QT_NO_KEYWORDS (seit Qt-4.1)
- Q_SLOTS
- Q_SIGNALS
und schaut sich die darunter stehenden Funktionen (Rückgabewert void!) an. Dann schreibt moc eine .moc Datei, die die Signaturen als c-string enthält, z.B.:
static const char qt_meta_stringdata_LCDRange[] = {
"LCDRange\0\0value\0valueChanged_(int)\0"
};
Zur Laufzeit werden dann c-strings miteinander verglichen und die entsprechenden Funktionen aufgerufen. Wählt man jedoch einen Slot oder Signal das gar nicht existiert, so wird der Compiler anstandslos seine Arbeit verrichten. Erst zur Laufzeit gibt Qt eine Fehlermeldung wie
Object::connect: No such slot LCDRange::value_changed_(int)
aus.
Bei sigc++ überprüft der Compiler ob die Signatur der Slots und Signale.
Ich persönlich lasse mir gerne vom Compiler auf Verwechselungen und Tippfehler hinweisen ;)
Wie in diesem Artikel
A Deeper Look at Signals and Slots
beschrieben lassen sich seit Qt-4.1 (korrekt?) auch template basierte Signal/Slot Bibliotheken wie boost.signals und sigc++ verwenden.
MfG Maik
2. erlaubt das Meta-system zudem die Manipulation (neue hinzufügen, vorhandene entfernen oder abändern) von signalen, slots und sogar kompletten Objekten zur Laufzeit.
3. ist auch das kurzfristige blocken, umlenken, mappen oder manipulieren von signals+slots kein Problem.
> wesentlich eleganterere loesung
Was irgendwelche "C++-Gurus" denken, interessiert mich nicht, die durchschnittliche C++-API ist nicht gerade sehr elegant und lesbar.
Der einzige Grund für libsigc++ mag sein, dass zur Kompilierzeit geprüft wird, ob signal und slot zueinanderpassen.
Ansonsten weiß ich nicht, warum
sigc::signal signal_detected;
...
mydetector.signal_detected.connect( sigc::ptr_fun(warn_people) );
besser lesbar sein soll als
signals:
void detected();
...
connect( mydetector, SIGNAL(detected()), this, SLOT(warnPeople()) );
Der moc nimmt einem Arbeit ab, indem er (sauberen) Code generiert und erlaubt es mir, meinen eigenen Code eleganter und besser lesbar zu gestalten. Also wo ist das Problem?
> Und was an DCOP besser sein soll als an CORBA,was ja durchaus keine gnome erfindung
> ist,ist mir auch schleierhaft.
CORBA ist vollkommen overengineered und zu komplex für den Desktop. Die Komplexität hätte die Verbreitung in den Anwendungen stark behindert (dass fast jede KDE-Anwendung über DCOP bzw. bald DBUS ansprechbar ist, hätte es mit CORBA wohl nicht gegeben). Das hörte sich 1998 vielleicht noch toll an, aber heute kräht da kein Hahn mehr nach, zumindest nicht auf dem Desktop. Warum wohl ersetzt Gnome sein CORBA-Krempel durch das wesentlich elegantere DBUS, das auch noch sehr ähnlich zu DCOP ist? Neben der unnötigen Komplexität für die Entwickler war damals der wesentliche Grund für DCOP die unzureichende Geschwindigkeit und der hohe Ressourcenverbrauch von CORBA.
> Ich persoenlich finde Qt zum kotzen,gross,aufgeblasen,und irgendwie immer den drang
> alles selber machen zu wollen,vom XML parser bis zur DB Anbindung.
Qt4 ist modular (QtCore, QtGui, QtSql, QtXml), niemand zwingt dich, alle Module zuverwenden. Wenn man es aber doch tut, hat man eine gute designte API (was man nicht von allen anderen der alternativen APIs behaupten kann), die auf allen von Qt unterstützten Plattformen zur Verfügung steht. Warum soll ich für ein paar kleinere Xml-Dateien die ich parsen will mit libxml2 abplagen, wenn ich mit QtXml eine wesentlich elegantere API gleich mitgeliefert bekomme?
Was ist mit den gnome anwendungen? sind die ueber corba ansprechbar? ohne orbit geht ja bei gnome nix,lass mich aber gerne belehren.
Naja DBUS hoert sich am anfang ganz toll an,aber ich frage mich ob es auch das abdeckt woran man erst in 3-4 jahren denkt,oder ob man es da erweitern werden muss. Kann man ueber DBUS netzwerktransparent arbeiten?
wenn es sauber modularisiert ist,find ich das gut. btw speziell ueber qtxml habe ich aber auch schon einiges schlechtes gehoert,vorallem das es langsam sein soll...
Es geht also weniger um theoretische Möglichkeiten, sondern um praktische Umsetzungen. CORBA/Orbit mag zwar netzwerktransparent sein, aber wieviele Gnomeprogramme nutzen Orbit in dem Maße wie KDE-Programme DCOP nutzen? KDE's Philosophie ist Pragmatismus und praktische Umsetzung von Lösungen im großen Stil und nicht die reine Lehre.
Das QT/Moc-Signal/Slots-Dingens ist meines Wissens wesentlich älter als analoge Konzepte in anderen Libs. Man sollte also Qt/Trolltech nicht vorwerfen, dass sie die ersten waren.
Hmm dann bin ich als theoretischer Informatiker bei KDE wohl einfach falsch...mir erscheint dbus jedenfalls mehr hingeschustert nach dem was man gerade braucht,als wirklich von grundauf durchdacht und geplant und funktioniert-fass-nie-wieder-an,also weit weg von der reinen Lehre.
Ich hab keine ahnung in wieweit DCOP oder CORBA genutzt werden,ist das denn wichtig wenn man ueber deren maechtigkeit redet? ;-)
Ja klar in Qt sind manche dinge historisch so,aber muss man deswegen dabei bleiben?
DCOP wird von jedem KDE-Programm genutzt (die meisten sehr ausgiebig). CORBA/Orbit unter Gnome hingegen nur recht wenig. Mächtigkeit allein reicht nicht aus, eine Lösung muss dem normalem Programmierer auch als das Natürlichste auf der Welt erscheinen, sonst nutzt er es niemals in großem Stil. Und DCOP und nun das nach seinem Vorbild geschaffene DBUS scheinen genau dieser Erwartung zu entsprechen.
Naja Qt hat mit jedem neuen Major Release die Codekompatibilität gebrochen insofern kann sich viel ändern. Der Grund für das Festhalten an den lange existierenden Eigengewächsen bei Qt ist auch: Es muss auf einigen vielen Nicht-(Standard-)-Unixplattformen laufen. Und da sich sehr auf Libs von anderen verlassen, die dann dort nicht laufen, man in speziellen Versionen plötzlich selbst pflegen muss oder sich plötzlich ändern ist da natürlich ein ziemliches Problem.
Ja? Und in welcher Weise?
> Ich hab keine ahnung in wieweit DCOP oder
> CORBA genutzt werden,ist das denn wichtig
> wenn man ueber deren maechtigkeit redet?
Unnötig komplexe Lösungen bedeuten mehr Einarbeitungsaufwand für die Entwickler, daher geringere Nutzung. Ein RPC-Mechanismus, den kaum jemand nutzt, ist wertlos. Ein OSS-Entwickler kauft sich kein dickes Buch über RPC-Framework X, nur um seiner Anwendung 5 RPC-Methoden hinzuzufügen. SAP kann seine Mitarbeiter auf Schulungen schicken und die werden gut dafür bezahlt, sich mit SAPs Monster-Architekturen zu beschäftigen. Im OSS-Bereich benötigt man eher "Instant Gratification", erste Schritte sollten einfach sein, damit der Entwickler (die meisten verwenden ja ihre kostbare Freizeit darauf) nicht das Interesse verliert.
Ein weiterer Grund für DCOP statt CORBA war außerdem die geringe Performance von CORBA:
"However, after a year of attempting to make heavy use of CORBA in KDE, we have realized that it is a bit slow and memory intensive for simple use. It also has no authentication available."
http://developer.kde.org/documentation/other/dcop.html#sec1
Das ist durchaus im Bereich des möglichen, denn die D-Bus API abstrahiert die Art der Übertragung. Selbst eine Applikation, die entgegen allen Empfehlungen keine Bindings sondern die Basis API benutzt, sieht nur D-Bus Messages.
Möglicherweise ist die D-Bus Implementierung unter Windows sogar loopback/TCP basiert, ich bin da nicht ganz auf dem Laufenden.
Derzeitiger Defaulttransport unter Unix sind Unix Domain Sockets, das ist nicht nur schneller, sondern hat auch Vorteile bei der Authentifizierung, usw.
Richtig breit durchgesetzt hat sich das bei Gnome nie, wenn man es mit DCOP unter KDE vergleicht. Und jetzt bewegen sie sich ja in Richtung DBUS.
> aber ich frage mich ob es auch das abdeckt woran man erst in 3-4 jahren denkt
Woran man in 3-4 Jahren denkt wird man erst in 3-4 Jahren wissen. Alle Fälle gleich mit einbauen zu wollen, weil man sie ja irgendwann mal gebrauchen _könnte_, führt nur zu ineffizienten und over-engineered Lösungen. Dann hat man ein komplexes Monster, das keiner so richtig versteht und deshalb auch die meisten nicht in ihre Software integrieren. Man kann nicht mehr machen, als modular genug zu designen, so dass man das Konzept später entsprechend erweitern kann.
> maechtig sind..
Ja, genau das, was CORBA nicht ist. Open Source-Projekte wie KDE arbeiten eher iterativ, d.h. man schaut erstmal darauf, was man wirklich zur Lösung der aktuellen Probleme braucht, implementiert es, und achtet darauf, dass es Erweiterungen erlaubt. Man baut nicht prophylaktisch irgendwelche Funktionalität ein, die _vielleicht_ mal jemand benötigen könnte. Dabei liegt der Schwerpunkt von DCOP/DBUS auf dem Desktop, und eben nicht in großen verteilten Anwendungen.
Abgesehen davon, daß der moc auch Code für Introspection generiert, sind die beiden Signallösungen ohnehin nicht vergleichbar, weil sig++ die Verbindung zu Compilezeit auflöst, aber Qt zur Laufzeit. Beides hat seine Vor- und Nachteile.
irgendwie immer den drang alles selber machen zu wollen,vom XML parser bis zur DB Anbindug
Diesen Drang nennt man Kundenwunsch :)
Ein Application development framework muß auf allen Plattformen die es unterstützt, die Basisfunktionalität heutiger Programme abdecken, d.h. GUI, Dateizugriff, XML, Netzwerk, Datenbank.
Mit GTK+ läßt sich das nur bedingt vergleichen, das es, wie du schon selber geschrieben hast, ein UI Toolkit ist.
>Pizza kommt vom Pizzaman!".
? ... bistŽe sicher ? ... "meinst Du daß, das was Du Atmest Luft ist ? ...
:-) (Matrix)
Tatsache ist doch, dass die meisten Gnome- und KDE-Nutzer nur ungern den Desktop wechseln. Du kannst gerne eine Einheits-Distribution machen, aber wenn dort kein KDE unterstützt wird, werden ich und viele andere sie nicht nutzen. Shuttleworth und (K)Ubuntu machen das schon ganz richtig. Warum, glaubst Du, ist das zur Zeit die angesagteste Distribution? Das hat auch damit zu tun, dass KDE und Gnome beide hervorrragend unterstützt werden.
Linux ist nicht trotz der verschiedenen Optionen so erfolgreich, sondern gerade wegen!
Im Moment treiben dich KDE und Gnome gegenseitig an.
Ich finds prima. Die "Einheit" kommt durch Schnitstellen zur Interoperabilität zustande.
Da tut sich was, das finde ich viel besser.
Gruß
Allerdings ist Linux gegenwärtig noch eine Art Asylheim für Flüchtlinge und Vertriebene, die ihre ursprünglichen Systeme mehr oder weniger durch die Dominanz von WindowsXP verloren haben -- da ist erstmal kulturelle Vielfalt angesagt, weil jeder etwas anderes gewohnt ist.
Irgendwann werden sich die Leute aber fragen, warum sie sich mit GNOME beschäftigen sollten, wenn es KDE gibt, und andersherum: Der durchschnittliche Apache-Anwender fragt auch selten nach Alternativen zu Apache. Und wäre Photoshop kostenlos erhältlich, würde auch niemand nach The GIMP fragen.
Zwischendrin wird es noch einige geben, die fragen, welche Teile von GNOME und welche Teile von KDE Sinn machen, und sie werden versuchen, beides zu kombinieren. Man sieht es ja jetzt schon an Experimenten wie Dolphin, der Konzepte von Nautilus stärker gewichtet und viele Fähigkeiten des Konquerers weglässt.
Von daher ist Warten angesagt, bis eine der Desktop-Umgebungen in einem bestimmten Sprachraum schlicht ausstirbt. Fans und Entwickler haben bezüglich ihrer Software nunmal keinen Abstand und überbewerten jeden minimalen Unterschied der Bedienung masslos. Alle anderen aber werden sich an das einzige objektives Kritierium halten: ob eine Desktop-Umgebung von den meisten anderen Menschen in ihrer sozialen System auch benutzt wird.
Also macht das Verhalten von Shuttleworth schon Sinn: Er orientiert sich an der gegenwärtigen Nachfrage des Geek-Publikums und legt seine Eier nicht alle in einen Korb.
Btw. Es fragen viele Apache Anwender die ich kenne nach Alternativen, und ich kenne auch einige die ich ohne zögern einem Apachen vorziehen würde.
In diesem Zusammenhang: Die drei Topgründe, KDE zu benutzen! Mal ehrlich: Die sind für die 90% der Anwedner subjektiv oder bedeutungslos -- also für den Büroangestellten oder die Hausfrau zu Hause.
Auch sehr schön an diesem Blogpost: Der offensichliche Mangel an Ahnung! Da ist also schon ein Geek, der ein Blog hat, und sich auch noch über die Desktop äußert, aber trotzdem hat er nicht herausbekommen, daß die Funktion "Open in Terminal" für Nautilus in eine seperaten Paket untergebracht ist, dass man nachinstallieren muß. Lustig auch, daß in den Kommentare sich promt ein zweiter Geek als ebenso planlos outet, und seine eigene geschrieben Lösung promotet!
Wäre ich ein Geek, müßte ich jetzt wohl schrieben, was für Trottel das sein müssen: Sie konnten offensichtlich nicht mal mit Google umgehen. Aber objektiv betrachtet fehlte ihnen wohl nur die Zeit, auch nur einen zweiten Desktop hinreichend gut kennenzulernen!
Und wenn das schon einem Geek passiert, wie sollten sich 90% der übrigen Desktop-Anwender damit auseinandersetzten können? Insofern entspringt deine Äußerung wohl eher Wunschdenken.
Übrigens: Auch Du machst den typischen Fehler und verwechselst Existenz mit Relevanz! Enlightment existiert nach wie vor, nur ist es für den Desktop nicht relevant. Wenn ich von Aussterben spreche, meine ich Relevanz. Natürlich wird es beide DEs immer geben: Der Windowmanager Sawfish existiert auch noch, aber relevant ist er nicht (mehr).
*lach*
> Der Normalanwender kann darin wahrscheinlich nur wenig mehr Unterschiede erkennen [...]
So geht es mir, wenn ich die Abdeckung meines Fernsehgerätes öffne. Was sagt das über die Relevanz der Argumente der Entwickler aus? Das ein Normalanwender bei Benutzung entsprechender Distributionen keinen Unterschied in der Benutzung (mehr) bemerkt, liegt an den Bemühungen vieler Entwickler, einheitliche und wiedererkennbare Elemente in der Gestaltung zu verwenden. Das allein ist aber noch lange kein Grund dafür, das GNOME oder KDE irrelevant sind.
> Mal ehrlich: Die sind für die 90% der Anwedner subjektiv oder bedeutungslos
Ehrlich ja, richtig nein. Ohne Entwickler keine Software, ohne Software kein Angebot für die Benutzer. Nicht jeder Qt/KDE-Entwickler hätte seine Anwendung unter Gtk/GNOME geschrieben - und umgekehrt. Warum wohl? Weil sich für verschiedene Anforderungen verschiedene Lösungswege anbieten, weil bei mehreren Lösungswegen persönliche Geschmäcker entscheiden und weil jeder Lösungsweg seine berechtigten Argumente besitzt.
> Wäre ich ein Geek, müßte ich jetzt wohl schrieben [...]
Aber zum Glück bist Du kein Geek, Du bist einfach so der Größte. ;)
> Und wenn das schon einem Geek passiert, wie sollten sich 90% der übrigen Desktop-Anwender damit auseinandersetzten können?
Man muss nicht jede Alternativlösung kennen, um eine bestimmte zu bevorzugen. Selbst wenn ich subjektive Gründe habe, auf meine Lieblingsdesktopenvumgebung zu setzen, was stört Dich das denn?
> Auch Du machst den typischen Fehler und verwechselst Existenz mit Relevanz!
Und Du machst den typischen Fehler des Egomanen und verwechselst "Relevanz für mich" mit "Relevanz für die Allgemeinheit".
Ich muss jedesmal schmunzeln, wenn ich solche "lasst uns das doch verallgemeinern"-Diskussionen sehe. Unterstellt man mal, das die insgesamt chaotisch agierende Gemeinde freier Softwareentwickler den diversifizierten Wunsch der Entwickler und Anwender nach einer für sie maßgeschneiderten Lösung darstellt, so kommt man zu einer interessanten Beobachtung: Obwohl hier offensichtlich die globale, ordnende, "rationalisierende" Hand fehlt, gibt es an allen Ecken und Enden Standards, Normen, Zusammenarbeit. Ganz offensichtlich ist man also selbst unter diesen Bedingungen in der Lage, bei wirklich wichtigen Punkten an einem Strang zu ziehen. Vielleicht normiert man deshalb keine einheitliche Desktopumgebung, weil es keine reale Notwendigkeit dafür gibt?
lg
Erik
Du unterstellst mir eine Meinung, die ich nicht geäußert habe: Mir ist völlig gleich, was oder wie Du Deinen Computer benutzt. Das immer wiederkehrende Entwickler-Argument -- "wir machen, was wir wollen" -- juckt mich ebensowenig: Wenn irgendjemand meint, seine Zeit mit der Entwicklung von Enlightment oder ähnlichem zu verbringen, ist das sein Bier.
Auch Deine Unterstellung, ich würde mir eine einzige Desktop-Umgebung wünschen, zeigt nur, daß Du derjenige bist, der sich von Vorurteilen leiten läßt: Ich habe nicht geschrieben, es sollte nur eine Desktop-Umgebung geben. Ich sagte, es wird irgendwann nur noch eine relevant sein.
Wenn Du also demnächst jemandem unterstellst, ein Egomane zu sein, dann versuche zuerst, Dein Gegenüber zu verstehen. Danke.
Im übrigen ist das Argument, manche Entwickler hätten vielleicht bei einer einheitlichen Umgebung niemals etwas anderes programmiert, zwar zutreffend, aber leider unvollständig: Vielleicht gab es auch Entwickler, die sich durch den Mangel an Einheitlichkeit haben abschrecken lassen. Da die Menge der möglichen und tatsächlichen Beiträge dieser beiden Gruppen unbekannt ist, ist das Argument ziemlich schwach.
Dann sieh bitte "ich" als "die anderen Anwender". Hoffe, mein Standpunkt wird dadurch klarer. Weder Du noch ich wissen vollständig, was Anwender brauchen. Deshalb sind Pauschalaussagen über den Sinn oder Unsinn von Softwareangebot und -nachfrage völlig falsch.
> Auch Deine Unterstellung, ich würde mir eine einzige Desktop-Umgebung wünschen, zeigt nur, daß Du
> derjenige bist, der sich von Vorurteilen leiten läßt
Nein, ich lasse mich von dem leiten, was ich von Dir gelesen habe. Darf ich zitieren?
zwei komplette Desktopumgebungen zu entwicklen, ist völlig sinnlos
> Wenn Du also demnächst jemandem unterstellst, ein Egomane zu sein, dann versuche zuerst,
> Dein Gegenüber zu verstehen. Danke.
Wenn er sich klar ausdrückt, kann man ihn auch verstehen. Und noch etwas, erinnerst Du Dich noch?
Wenn Du GNOME und KDE als "zwei komplett unterschiedliche DE Konzepte" bezeichnet, sagst Du nur, dass Du ein Geek bist.
Nun spiele mal nicht die beleidigte Leberwurst, nur, weil Dir der Wind mal so entgegenpustet, wie Du es vorher mit Michael veranstaltet hast.
> Im übrigen ist das Argument [...] zwar zutreffend, aber leider unvollständig
Richtig. Es mag sein, dass sich Jemand von der Diversifikation der Umgebungen abschrecken läßt. Ich versuchte auch lediglich klarzumachen, dass die Allgemeingültigkeit, die Deine Aussagen durch Formulierungen wie "es wird irgendwann nur noch eine relevant sein", "sind [...] subjektiv oder bedeutungslos" suggerieren, nicht gegeben ist. Dementsprechend schwach ist das, was Du eigentlich von Anfang an sagen wolltest.
lg
Erik
Ich gebe Dir auch gerne recht, dass Pauschalaussagen nach Softwareangebot und -nachfrage gefährlich sind. Vielleicht ist Dir ja aufgefallen, dass ich keine Aussage darüber gemacht habe, welche Desktop-Umgebung dominieren wird.
Es gibt aber historische Erfahrungen -- wie etwa die wachsende Dominanz von Photoshop oder beispielsweise die Tatsache, dass Firmen in Stellenanzeigen Erfahrungen mit spezieller Software verlangen --, die vermuten läßt, dass die Monopoltendenz im Software-Markt nicht nur auf Anbieterseite zu suchen ist, sondern auch ganz stark auf Nachfragerseite.
Insofern wage ich eine Prognose. Ich gebe gerne zu, dass sich diese in Zukunft als falsch erweisen kann.
Das ist eine Interessant Beobachtung die ich auch immer wieder mache.
Ich habe in meinem Bekanntenkreis viele Windows Benutzer und 2 MacOS Benutzer. Alle sind keine "Geeks" sondern verwenden halt einen PC auf der Arbeit und surfen zu Hause etwas im Internet usw.
Ich habe KDE und GNOME installiert und wechsel auch ab und zu mal gerne. Wenn jetzt aber die anderen (win und MacOS Benutzer) bei mir sind und mir über die Schulter schauen oder auch mal kurz meinen PC benutzen, dann fällt denen weder auf, dass es gestern GNOME war und heute KDE ist noch das es etwas komplett anderes wie ihr windows oder MacOS ist. Ich kann es mir nicht erklären, aber irgendwie scheint für den "normalen" Anwender alles gleich zu sein.
Ich behaupte mal der durchschnittliche Leser auf Pro-Linux wird Schwierigkeiten haben, zwei Impressionisten auseinander zu halten, während eine Kunststudentin keinerlei Probleme damit hätte.
Oder betrachte es andersherum. Selbst wenn einer Deine Bekannten fragen sollte: "Sag mal, hast Du etwas geändert?" und Du dann antworten würdest: "Ja, ich habe ein paar Einstellungen verändert und ein neues Theme installiert", so wäre das wahrscheinlich eine ebenso plausibele Antwort für die wie: "Ja, das ist KDE und das vorher war GNOME."
Naja, ich kann vielleicht nicht die Band, den Rapper oder die Briefmarke genau klassizifieren oder sagen welche Briefmarke mehr Wert ist. Aber mir fallen doch trotzdem unterschiede auf, ob die gleiche Band von gestern auf der Bühne steht oder nicht und das sie vielleicht einen anderen Stil haben (härter, softer, etc.),...
Aber das man so garnichts am PC merkt verwundert mich schon immer wieder. Das zeigt imho aber auch das so sachen wie "Einheitlichkeit" total überschätzt sind, zumindest mit Blick auf den "normalen"-user. Die unterschiede z.B. zwischen einem GNOME und KDE Programm (egal ob jetzt beide unter GNOME oder unter KDE ausgeführt werden) werden den meisten "normalen" Anwendern wahrscheinlich nicht auffallen bzw. nicht stören. Das merkt man ja auch daran, dass sie zum Teil auch unter Windows Shareware/Freeware verwenden die zum Teil ganz andere UIs haben als die "professionelle" Software und groß gestört hat sich daran bisher noch niemand.
> wie "Einheitlichkeit" total überschätzt
> sind, zumindest mit Blick auf
> den "normalen"-user.
Gerade "normale" Benutzer benötigen einheitliche Oberflächen, die sich möglichst gleich verhalten. Dann lernt man einmal und kann dann sein Wissen überall anwenden. Wenn jede Anwendung andere Konzepte und Begriffe für dieselbe Funktionalität verwendet, ist der Benutzer verwirrt. Dazu gibt es genug Untersuchungen im HCI-Bereich, z.B. zu Effektivität des Arbeitens je nachdem wie einheitlich Menü-Optionen etc. benannt sind.
Wer hat bloss dieses Gerücht in die Welt gestzt ?
Im US Raum sieht es nicht anders aus wie hier. Es gibt viele US Distributionen, die setzen nur auf KDE, andere nur auf GNOME.
Bitte nicht einfach nachplappern was Miguel de Izcara vorbetet.
Was man hingegen wohl als Tatsache verbuchen kann ist, dass Gnome von fast allen großen hauptsächlich auf den Servermarkt orientierten IT-Softwareanbietern favorisiert wird. Den Ausschlag werden wohl neben Zufällen (der Linux-Serversoftware-Shooting-Star Red Hat hatte halt Gnome und war als größter Linuxdistributor somit deren Vergleichsmaßstab Nummer 1) psychologische Gründe gewesen sein, wie dass man Gnome als traditioneller und konservativer und somit als "ernsthafter" empfand (C vs. C++ ). Und dann natürlich die Tatsache, dass KDE im Gegensatz zu Gnome eine komplett andere Beteiligung durch Firmen aufweist, die es für große Kapitalgesellschaften schwer macht dort die Richtung vorzugeben (und angesichts der Hühott-Bewegungen in Gnome möchte man meinen Gottseidank): An KDE beteiligen sich neben der allgemeinen Community hauptsächlich "personenfixierte" Unternehmen, wie mittelständige GmbHs (etliche Beispiele in Europa), Aktiengesellschaften in Mitarbeiterbesitz (insbesondere Trolltech) und selbst Suse hat in dieses Bild mentalitätsmäßig reingepasst (auch wenn sie durch Fremdkapital finanziert waren).
So Geschmarri wie an den Haaren herbeigezogene Lizenzprobleme und so hat da niemals die Firmen interessiert, das waren Ausflüchte.
Er ist meines Wissens Niederländer. Zumindest wurde er laut People Behind KDE-Interview in den Niederlanden geboren.
> KDE arbeiten wüsstest
Allen Winter (kdepim), Scott Wheeler (juk, taglib, wohnt allerdings in D), Ryan Nickell (Superkaramba/Plasma), Wade Olson (PR), Ian Monroe (Amarok), Celeste Paul (Usability), Ian Geiser (Core), Chris Lee, Matt Rogers (Kopete), Benjamin Meyer (aus den USA, jetzt bei Trolltech), George Staikos (Core), Gary Cramblitt (Accessibility), Eric Laffoon (Quanta, Kommander)
13!
Reicht das fürs erste?
Das sind alles recht aktive, zum Teil äußerst aktive Leute, auf http://worldwide.kde.org finden sich auch noch mehr. Zugegeben, in Europa ist der Teppich noch deutlich dichter.
as dir aber auch völlig entgangen ist: Man sollte solche Vorschläge mal in aller Ruhe zu Ende denken, dann zeigen sich meist schon die dicksten Patzer im Ansatz... Die meisten Gnome- oder KDE-Entwickler arbeiten in erster Linie für sich selbst - nenn es ein Hobby, eine Berufung, was auch immer - klar ist nur eins: DIE sind niemand, die für DICH irgendwas tun sollten oder müssen. Denn du hast kein Geld bezahlt, höchst warscheinlich noch nichts nennenswertes beigetragen oder auch nur was gespendet. Und selbst dann hättest du kein Recht und keine Möglichkeit, von wildfremden Leuten zu fordern, sie mögen ihre Freizeit nach deinem Masterplan gestalten, um dann am Ende für dich die (Desktop)Welt zu beherrschen oder so. Was willst du tun - jeden nach Guantanamo schicken, der sich ein eigenes DE stricken möchte, weil er so viel Spaß dran hat? Programmiererlaubnis nur noch nach planwirtschaftlichen Kriterien vergeben?
Sorry für die harten Worte, aber ich selbst bin zufällig freizeitmäßig in solchen Fahrwassern tätig, und fühle mich von diesen quengligen Forderungen allmählich leicht verkohlt. Wir stellen phantastische Dinge auf die Beine, und ob sich irgendein Fuzzi von der Auswahl zwischen zwei unterschiedlichen Oberflächen überfordert/verwirrt fühlt, soll er da glücklich sein wo man keine Wahl bekommt. Ich mach das für mich und für die Leute mit ähnlichem Technologie-Geschmack, für niemand sonst.
sonnst kommt der ubuntugedanke alles alt bewärte durch neues zu ersetzen auch noch kde
sieht man ja an dem kubuntu kontrollzentrum sowas von unbenutzbar
Ach ja kleiner Hinweis: Es schaut komplett anders aus als das des Standard-KDE-Desktops, falls du wider erwarten doch noch kein Kubuntu gesehen haben solltest...
Und genau deswegen nehme ich GNOME :p
Und wozu sind Kontrollzentren da? Konfigurationsmodule zentral zu bündeln, damit man nicht an x verschiedenen Stellen mit x verschiedenen Tools rumbasteln muss.
Solange das KDE Projekt sich nich von seiner Kohle abhängig machen läßt ist das doch ne super sache so nen Multi Millionär als Finanzier im Rücken zu haben
EIgnetlich ein super ANsatz, man findet sich unter Kde und Gnome gleichermaßen durch das Theme (ist es überhaupt eines
Und wenn man Standard will einfach abschalten. Sowas genügt doch für den "Einheitsbrei".
http://ev.kde.org/corporate/supporting_members_german.pdf
Übrigens ist mit Sebastien Bacher (seb128) auch nur ein Entwickler für Gnome abgestellt, die anderen arbeiten ihm zu.
Bei KDE ist das mit Jonathan Ridell (ridell) ebenso genauso.
Mark meinte es einfach gut und hat nur das bekräftigt, was auch früher schon so galt.
(Falls jemand fragt, woher ich meine Infos habe: Ich war persönlich im Gegensatz zu dem Herrn M., der das ganze eigentlich angezettelt hat, übrigens beim IRC-Meeting, wo dies mit Mark Shuttleworth besprochen wurde. Ist aber alles in den IRC-Logs nachzulesen.)
@pro-linux: Diese Infos sollten euch aber bereits auch zugetragen worden sein und ich dachte nicht das diese Falschmeldung nochmal auftaucht.
Die "anderen" entwickeln z.B. den Kernel, die Build-chain, launchpad, betreuen die mirror usw. usw.
Von all dem profitieren auch die KDE jungs (die ihren job übrigens gut machen) ebenso.
von einem *nur dem Gnome-Entwickler* kann also wirklich keine rede sein.
Jedoch sind viele Projekte und Forks eine ein-Mann-Shows, die mit bestehenden quelloffenen Lösungen nicht zufrieden sind und selbst ein neuen Versuch starten. Das ist sicherlich positiv für die Innovation falls es tatsächlich ein Problem mit der bestehenden Lösung gibt (siehe Mimix und Linux).
Doch bei vielen Projekten habe ich den Eindruck dass das Rad einfach neu erfunden wird und dass es zu einer Zersplitterung kommt. Deshalb haben wir viele "Halb-Lösungen" zu kommerziellen Software. Wäre es nicht besser wenn die Opensource Entwickler ihre Kräfte besser bündeln würden?
Ich trage selbst zu einem quelloffene Software Projekt (www.octave.org) bei und staune oft darüber wie viele alternative Projekte es gibt, die das selbe Ziel haben, nämlich das kommerzielle Programm Matlab nach zu bauen. Alle Projekte, die ich kenne sind jedoch immer noch ziemlich weit von diesem Ziel entfernt.
Da würde ich den Leuten vielleicht mal eine E-Mail schreiben und freundlich anfragen ob es da Möglichkeiten zur Kooperation gibt. Kommunikation ist schon was schönes, Gnome- und KDE-Entwickler reden ja zumeist auch miteinander.
Allerdings wird auch öfter Zusammengearbeitet als man gemeinhin sieht. z.B. tauschen ReactOS und Wine Informationen und Codeteile aus.
Das ist sehr lobenswert. Die Ingenieur- und wissenschaftlichen Anwendungen wie MATLAB, Origin, Labview, etc. sind in der OpsenSource-Szene leider viel zu unterrepräsentiert. Wo doch gerade diese Anwender offenen Standards positiv gegenüber stehen.