> Der größte Teil der Plattform steht unter der LGPL. Aus dem Original: Following GNOME's highly successful licensing strategy, the GNOME Mobile & Embedded Platform is distributed under the terms of the LGPL, which allows for royalty-free use in proprietary software products, but encourages contribution of platform code changes back to the community. This, combined with a thriving open development process supported by industry and community, makes the GMAE Platform uniquely suited to the needs of mobile and embedded developers.
Ich lege meine Hand bestimmt nicht dafür ins Feuer, dass alles unter der LGPL steht. Prinzipiell können alle GNOME-Anwendungen Teil dieser Plattform werden, wenn ich das richtig verstehe.
Vielleicht bezieht es sich auf die Dinge für die Plattform die noch entwickelt werden wie das Java ME... das kommt doch vermutlich eher unter GPL oder? Ich es selber noch nach aber sehr viele Informationen sind noch nicht zugänglich.
Zur Zeit sind keine unfreien Komponenten enthalten. Welche Java ME Implementierung in erwaegung gezogen wird weiss ich nicht, von daher kann man dazu erstmal nichts sagen. Die anderen Komponenten die in Erwaegung gezogen werden sind ebenfalls frei.
Es ist nett, dass GNOME wieder einmal etliche Initiativen ankündigt und gerne überall mitmischen möchte. Nur sollte man den Hauptfokus und damit die Hauptinitiative nicht aus den Augen verlieren. Das meiner Ansicht nach ist und sollte weiterhin bleiben - Der GNOME Desktop.
Dieser ist immer noch sehr kaputt und kaum zu benutzen. Drucken funktioniert immer noch nicht gescheit. Ich kann immer noch keine PDF's mit mehreren Seiten auf einem Blatt Papier ausdrucken. Evolution stürzt weiterhin immer ab und macht den Email Index kaputt (desynchronisiert). Auch druckt GThumb weiterhin nur schwaze GIF Bilder aus. Die Abhängigkeiten zu HAL sollte man wieder sauberst entfernen.
Auch kann bei GNOME von keiner sauberen Integration die Rede sein (ich komme beruflich aus dem Integrationsumfeld). Es scheint keinerlei vernüftige Abstraktionsschichten zu geben, da die Tools teilweise direkt die DBUS, HAL oder GStreamer Bibliotheken aufrufen. Man fragt sich manchmal wozu Evolution wohl HAL brauchen könnte. Wenn, dann sollte man sowas in einer GNOME spezifischen Bibliothek unterbringen und die Anwendungen darauf zugreifen lassen.
KDE macht dies sehr gut vor, indem sie DBUS und HAL in einer Abstraktionsschicht packen und die Anwendungen darauf zugreifen lassen. Sollte man kein DBUS und HAL haben, so kümmert sich diese Abstraktionsschicht um weiteres und erlaubt, dass die Anwendungen weiterhin "Baubar" bleiben. Dies ist bein GNOME leider unmöglich, da wohl jedes dem Desktop zuzuordnenden Tools das wohl selber irgendwie hineinbastelt.
Es sind keine klaren Zielvorgaben zu erkennen, auch ist keine saubere Integration auszumachen. Bei KDE kann man davon ausgehen, dass das Grundsystem gut abstrahiert wird und die Applikationen auf diese Abstraktionsschicht zugreifen, bei GNOME weiss man, dass sich die Abhängigkeiten gerade wegen dem Fehlen dieser Abstraktionsschicht wie Krakenarme überall hineinvertiefen.
Bitte keine "nimm Ubuntu" Antworten, da dies nicht meine Kernaussage betrifft.
DBus, HAL und gstreamer sind doch schon gute Abstraktionsschichten. Warum denn nochmal was drüber packen?
Im Gegensatz zu KDE ist GNOME besser teil- und wiederverwendbar. Sugar (100$ Laptop) und GMEI (OpenMoko,Maemo) sind in gewissem Sinne genauso Gnome wie der Desktop von Ubuntu. Dass der Hauptfokus der Desktop ist, ist nicht so ganz klar.
Da 99% der Anwender die Funktionalitaet von HAL, D-Bus und GStreamer wollen (auch in mobilen Geräten) ist es Bloedsinn das ganze noch einmal zu abstrahieren.
In KDE ist DCOP notwendig. Statt der HAL-Abstraktionsschicht werden direkt irgendwelche Systemspezifische Routinen verwendet. Was ist an Phonon besser als GStreamer?
Phonon ist besser, weil der User die Wahl hat, ob er auf gstreamer, alsa, oss, xine oder sonstwas aufsetzen will. Für die Apps ist das was feines. Die müssen sich nur mit Phonon auseinandersetzen und brauchen sich nicht darum zu kümmern, was weiter unten geschieht.
> DBus, HAL und gstreamer sind doch schon gute Abstraktionsschichten. Warum denn nochmal was drüber packen?
Weil's das vieleicht NICHT bei BSD, Darwin, Windows etc. gibt ? Wenn's vorher vernünftig abstrahiert wurde, so könnte man der Abstraktionsschicht mitteilen "auf dieser Plattform nicht" und voila die Apps und was dazu gehört kann man dennoch compilieren ?
> Weil's das vieleicht NICHT bei BSD, Darwin, Windows etc. gibt ? Wenn es Bibliotheken, die ein Programm braucht auf einer anderen Plattform nicht gibt muss man sie halt portieren. Das müsste man auch mit einer Abstraktionsschicht machen.
Unterschiedliche Betriebssysteme haben auch vollkommen unterschiedliche Philosophien und Techniken. Man kann oftmals nicht einfach irgendetwas irgendwohin portieren. Da die Grundvorraussetzungen andere sind.
> > Weil's das vieleicht NICHT bei BSD, Darwin, Windows etc. gibt ? > Wenn es Bibliotheken, die ein Programm braucht auf einer anderen Plattform > nicht gibt muss man sie halt portieren.
D.h. du portierst z.B. eine Bibliothek zum Font-Rendering auf die Zielplattform, obwohl es die Funktionalität dort schon gibt (Windows und Mac OS X können Schriften darstellen, habe ich gehört).
- Damit vergrößerst du den Binärklumpen, den jemand installieren muss, um deine Anwendung laufen zu lassen. - Du erhöhst den Speicherverbrauch und senkst die Startgeschwindigkeit deiner Anwendung. - Du führst eine zweite, parallele Konfiguration der Schriftarten ein, die entweder inkonsistent mit der nativen ist oder von dir aktiv konsistent gehalten werden muss. - Du wirfst den Vorteil weg, die ausgetestete Bibliothek der Zielplattform für deine Zwecke einzuspannen. Das bedeutet mehr Bugs für deine Nutzer. - Wenn die Bibliothek nicht zufällig von dir gewartet wird (lies: oder deinem Team), dann hast du keinen Einfluss darauf, ob und wann die Portierung stattfindet. Oder du musst dich dort engagieren und dich in fremden Kode einarbeiten. Aber eigentlich wolltest du doch nur die Software, die dir schon vertraut ist und die dir am Herzen liegt (oder für die du bezahlt wirst (oder beides, das soll es geben), auf einer neuen Plattform anbieten können. Für diese Software bleibt dann entsprechend weniger Zeit.
Du anwortest, "Na, dann implementiere ich die Portierung eben so, dass sie die native Funktionalität benutzt."? In dem Moment hättest du die äußere Schnittstelle der Bibliothek zur Abstraktionsschnittstelle erhoben. Die ist dann aber vermutlich weit weniger sauber und elegant, als wenn man sie gleich mit diesem Ziel entworfen hätte.
> Das müsste man auch mit einer Abstraktionsschicht machen.
Ja, aber eine solche Schicht sollte so entworfen sein, dass sie dünn ist. Sie passt nur Vorhandenes an die definierte Schnittstelle an, statt das Rad komplett neu zu erfinden.
Du möchtest also, dass freie Programme auf Bibliotheken von Microsoft und Co. basieren und somit nicht mehr frei sind? Du willst allen ernstes dich von Colsed-Source abhängig machen?
>> Das müsste man auch mit einer Abstraktionsschicht machen.
> Ja, aber eine solche Schicht sollte so entworfen sein, dass sie dünn ist. Sie passt nur Vorhandenes an die definierte Schnittstelle an, statt das Rad komplett neu zu erfinden.
Und was ist wenn es in der Basisschicht nicht alle Funktionen gibt? Diese Fehler enthalten oder Funktionen einfach anders Interpretiert werden oder sie sich ändert...
Warum willst du eigentlich überhaupt Plattformunabhängigkeit?
> Du möchtest also, dass freie Programme auf Bibliotheken von Microsoft und Co. > basieren und somit nicht mehr frei sind? Du willst allen ernstes dich von Colsed-Source abhängig machen?
Wow, an anderer Stelle beschwerst du dich über die Diskussionkultur eines Posters, und hier kommst du mit solchen dümmlichen Unterstellungen.
Von "basieren" kann keine Rede sein. Die Abstraktionsschicht sorgt ja gerade dafür, dass die OpenSource-Anwendung sich nicht von MS abhängig macht.
Es wird dich erschrecken zu hören, aber jede OpenSource-Anwendung, die unter Windows läuft, benutzt direkt oder indirekt ClosedSource und ist nach deiner Definition nicht frei. Übrigens hat die GPL kein Problem mit dem Linken von Freier Software gegen Basisbibliotheken des Betriebssystems.
Außerdem: Wir reden von einem Port auf eine andere Zielplattform. Warum sollte meine Version unter Linux unfrei werden, nur weil es auch eine Windowsversion davon gibt und jemand eine Implementierung einer Schnittstelle geschrieben hat, die gegen die CSS-Plattformbibliotheken linkt?
> Und was ist wenn es in der Basisschicht nicht alle Funktionen gibt?
Die grundlegenden Probleme wie Hardwareerkennung oder Schriftdarstellung sollten auf den verbreiteten Plattformen zufriedenstellend gelöst sein, wenn nicht sogar besser als unter Linux / BSD / ... (z.B. wegen der besseren Verfügbakeit von Treibern)
Sollte das aber wirklich der Fall sein, dann ist eben mehr Arbeit gefragt und die Implementierung der Schnittstelle auf dieser Plattform wird dicker. Das ist immer noch weniger Arbeit und resultierender Ballast als bei Null anzufangen.
> Diese Fehler enthalten
Dann hat die Zielplattform einen Bug. Wenn die Systembibliotheken gravierende Fehler enthalten, sollte sie der Hersteller fixen, oder? Ach, ich vergaß, MS mag seine Nutzer ja nicht und fixt keine Bugs. Umso besser, haben sie einen Grund mehr, auf ein freies Betriebssystem zu wechseln. Das ist doch in deinem Sinne.
> oder Funktionen einfach anders Interpretiert werden
Tut mir leid, ich weiß nicht, was du hier sagen willst.
> oder sie sich ändert...
Das ist genau der Fall, bei der die Abstraktionsschicht punkten kann. Du änderst die Implementierung der Schnittstelle, und die ganzen Anwendungen, die gegen die Schnittstelle geschrieben sind, bekommen davon nichts mit.
Außerdem kann man MS wohl kaum Vernachlässigung der Rückwärtskompatibilität ihrer Betriebssysteme vorwerfen. Eher im Gegenteil, dass sie deswegen in der Vergangenheit zu viele Kompromisse gemacht haben. Siehe z.B. die zögerliche Einführung von Multinutzer und deren Rechten.
Dieser ist immer noch sehr kaputt und kaum zu benutzen
Also ich benutze ihn erfolgreich, und das seit Jahren. Was also soll denn so kaputt und schwer benutzbar sein?
Evolution? Habe ich... nutze ich... knapp 18.000 Mails im Archiv und arbeitet flott und stabil. Drucken? Geht auch wunderbar. Mag aber auch am Drucker liegen, dass er sich so bereitwillg hat einbinden lassen. Integration? Top kann ich da nur sagen. Was ich in Evolution verwalte steht mir in vielen Anwendungen und af dem Desktop zur Verfügung.
Du bist scheinbar nur ein weiterer gelangweilter GNOME Basher und KDE Troll... dann nutz doch weiter KDE aber red nicht über Dinge von denen du nichts verstehst und alle sind glücklich. Braucht dein Ego diese Provokation? Hechelst du nach dieser Aufmerksamkeit?
Ich arbeite erfolgreich und problemlos mit dem GNOME Desktop. DAS ist der Punkt. Es funktioniert einfach einfach.
Das war damit nicht gemeint. Gemeint war eher, das es hier Leute gibt die aus Trotz behaupten das bei Ihnen alles super Läuft und das alle Probleme nur an mir liegen. Der oben genannte Bug ist im übrigen 6 Jahre alt und immer noch nicht gefixt und täglich steigt die Liste derer, die sich in dieser Bugmeldung reinhängen. Ich bekomme nun seit Jahre täglich Rückmeldungen zu diesem Bug.
Ausserdem ist es nicht "ein bug" sondern es ist hier sehr ein kritischer Bug der nie wirklich beseitigt wurde. Solltest das mal lesen bevor du darauf antwortest. Nun will man ernsthaft das Evolution Data Server (genau da wo der Bug anzunehmen sei) auf portable Plattformen portieren ?
Warum ist seit einiger Zeit jeder, der Argumente liefert und auf Probleme bei GNOME hinweißt ein "GNOME Basher und KDE Troll"? Verstehe ich nicht. Ist eine kritische Meinungsäußerung über GNOME nicht mehr erlaubt? Und das die genannten Probleme bei Dir nicht auftreten, bedeutet noch lange nicht, dass GNOME völlig fehlerfrei ist und auf jedem Rechner läuft. Es sagt einzig und allein nur eines aus: bei Dir funktioniert es. Nicht mehr und nicht weniger. Und kann wohl kaum als Maßstab für alle GNOME-Installationen herhalten. Freu Dich darüber, aber gestehe anderen Anwendern zu, dass sie ihre Probleme schildern können.
Natürlich ist Kritik erlaubt, aber sie sollte sachlich sein. Natürlich ist GNOME nicht völlig fehlerfrei, aber welche Software ist das schon? Und das die genannten Probleme bei auftreten, bedeutet noch lange nicht, dass GNOME sehr kaputt ist und auf keinem Rechner läuft. Es sagt einzig und allein nur eines aus: bei Dir funktioniert es nicht. Nicht mehr und nicht weniger. Und kann wohl kaum als Maßstab für alle GNOME-Installationen herhalten.
> Natürlich ist Kritik erlaubt, aber sie sollte sachlich sein.
Was war denn daran nicht sachlich ?
> Natürlich ist GNOME nicht völlig fehlerfrei, aber welche Software ist das schon?
Hier differenziert man zwischen "nicht vollig fehlerfrei" (trifft nicht auf GNOME zu) und "vollkommen kaputt" (trifft auf GNOME zu). Fehler hat jede Software, nur die Anhäufung der Fehler in der Grundfunktionalität (ohne jetzt die weiteren Funktionalitäten zu betrachten) ist bei GNOME sehr hoch.
> Und kann wohl kaum als Maßstab für alle GNOME-Installationen herhalten.
Es geht hier nicht um GNOME-Installationen, sondern um das was man Programmcode nennt. Wenn der GNOME Code schon schlecht ist (und ich weiss das), dann kannste es installieren wo immer man möchte. Der Code bleibt schlecht. Der Vorteil den man vieleicht haben könnte ist, dass gewiefte Distributionsanbieter einige Codemonkeys irgendwo sitzen haben, die diese Bugs nach und nach rausbasteln.
Ich gehe jetzt mal auf dein Originalbeitrag ein, den du am Sa, 21. Apr 2007 um 8:55 geschrieben hast. 1. Übertreibungen, wenn du wirklich sachlich sein willst solltest du Übertreibungen nicht verwenden. Beispiel: "GNOME wieder einmal etliche Initiativen ankündigt" GNOME hat nur eine Initiative ankündigt, also warum etliche?
2. Nachweislich falsche Behauptungen: Beispiel: "... weiterhin "Baubar" bleiben. Dies ist bein GNOME leider unmöglich ..." Das GNOME "Baubar" ist doch alleine schon damit bewiesen das ich es gerade benutzen. Also muss es ja möglich sein.
Schau mal in deinen Text ob du noch mehr Textstellen findest die unsachlich seien könnten. Wenn du keine weiteren findest bin ich dir auch gerne noch mal behilflich.
>> Natürlich ist GNOME nicht völlig fehlerfrei, aber welche Software ist das schon?
> Hier differenziert man zwischen "nicht vollig fehlerfrei" (trifft nicht auf GNOME zu) und "vollkommen kaputt" (trifft auf GNOME zu). Fehler hat jede Software, nur die Anhäufung der Fehler in der Grundfunktionalität (ohne jetzt die weiteren Funktionalitäten zu betrachten) ist bei GNOME sehr hoch.
Das "vollkommen kaputt" habe ich oben in der Liste noch nicht ist aber ersten keine sehr sachliche und konstruktive aussage und zweitens stimmt es zumindest für meine Installation nicht zu.
>> Und kann wohl kaum als Maßstab für alle GNOME-Installationen herhalten.
> Es geht hier nicht um GNOME-Installationen, sondern um das was man Programmcode nennt. Wenn der GNOME Code schon schlecht ist (und ich weiss das), dann kannste es installieren wo immer man möchte. Der Code bleibt schlecht. Der Vorteil den man vieleicht haben könnte ist, dass gewiefte Distributionsanbieter einige Codemonkeys irgendwo sitzen haben, die diese Bugs nach und nach rausbasteln.
Killerargumente wie diese solltest du in einer sachlichen Diskussion auch meiden. Ich habe jetzt keine Möglichkeit dies zu widerlegen, zumindest nicht ohne auch ein Killerargument anzuwenden. Aber ich versuche es trotzdem einmal. Du schreibst, "Es geht hier nicht um GNOME-Installationen, sondern um das was man Programmcode nennt." Ich würde bei der Qualität von Programmen dort keinen zwingenden unterschied machen. Oder möchtest du behaupten das ein Compilat besser als sein Quellcode sein kann? Und weiter schreibst du, "... gewiefte Distributionsanbieter einige Codemonkeys irgendwo sitzen haben ..." glaubst du den wirklich, das die Distributionen die Bugs, die sie raus machen nicht in das Basisprojekt zurückfließen? Ich habe von dem Quellcode keine Analyse gemacht, das währe wahrscheinlich auch ein Projekt von mehreren Jahren. Was ich allerdings sagen kann ist das ich schon seit 2002 Evolution benutze das unter SuSE, Debian und jetzt Ubuntu. Meine älteste Mail die ich gerade finden konnte ist vom 04 May 2002 15:24:05 +0200, geschrieben mit Ximian Evolution 1.0.3. Ich hatte seitdem unter Gnome und Evolution keine Datenverluste, was ich vorher mit KMail Version 1.3 schon hatte. (Ich denke KDE ist seit dem aber auch besser geworden.)
Aber ich glaube du hast recht. Die Distributionen haben alle Programmierer, die nichts besseres zu tun haben und die Fehler für mich raus zu machen und bei dir wider rein.
Ich antworte zu diesem Thread als auch zu dem da oben.
Das hat nichts mit Argumenten oder Sachlichkeit zu tun, sondern ganz einfach damit, dass ich diese Art der Konversation schon seit Jahren kenne und sie am Ende zu nichts führt. Man dreht sich permanent im Kreis und kommt mit dem was man aussagen möchte nicht weiter. Es kommt eine Aussage zur Nächsten und am Ende verliert man jegliche Übersicht zu dem was man eigentlich Aussagen möchte.
Wir sind uns doch alle einige und auch klar darüber das GNOME überall Fehler hat. Gut, es gibt nichts was keine Fehler hat, nur stellt sich meiner Ansicht nach es so dar, dass bei GNOME die Anzahl der Fehler einfach zu hoch ist, um damit gescheit zu arbeiten.
Jetzt kommt natürlich wieder die Argumentation, das aussgerechnet bei dir natürlich seit jahrzehnten alles ohne jeglichen Absturz und ohne jegliche Probleme alles einwandfrei und super lief. Wie kann das aber sein, da wir uns doch einige sind das GNOME nicht frei von Fehlern sein kann. Einer von uns muss demnach ja nicht die Wahrheit sagen. Nur weil ich diese ganzen Fehler auf dem Punkt bringe und behaupte das GNOME kaputt ist, so fühlst du dich auf den Schlipps getreten und startest hier eine "Quarschkonversation". Du hast einfach keinen Plan von dem, was du da sagst und willst hier nur Personen und User dumm darstehen lassen. Ist klar natürlich mein Fehler das GNOME nicht funktioniert.
Meine Güte....
Das genau das Problem bei Open Source... Einfach zu viele Egos und Alteregos die zuviel Politik in die Runde werfen. Ich habe im Eingang klar erwähnt, was die Probleme sind. Für mich bestehen diese Probleme weiterhin. Auch zu dem einen Link zum Evolution Bug (der seit 6 Jahren bekannt ist, aber natürlich in genau deiner Evolution Version nie auftrat) trat leider bei etlichen anderen Usern auf. Genau Heute habe ich zu diesem Bug wieder 2 Mails erhalten.
> Wir sind uns doch alle einige und auch klar darüber das GNOME überall Fehler hat. Genau das sind wir ja nicht. Wir können und darauf einigen das Gnome Fehler hat. Und auch darauf, das jeder Fehler ein Fehler zuviel ist. Und auch das ein Bugreport 6 Jahre offen bleibt ist eindeutig zuviel. Dies zeigt aber auch, das dieser Fehler wohl auch bei den Entwicklern nicht auftritt. Denn das weiß ich aus eigener Erfahrung, dass Fehler die die Entwickler selber stören sehr schnell verschwinden.
Warum tritt der Fehler also nicht bei mir auf aber bei dir? Deine These ist also alle die mit Gnome/Evolution ohne Probleme arbeiten lügen. Warum sollte ich das machen? Ich verdiene mein Geld nicht mit Gnome oder Linux hab also keine finanziellen Vorteile. Wenn mich so ein Fehler so nerven würde würde ich zu einem anderen E-Mail Programm wechseln. Es gibt ja gute andere für Linux. Also ich lüge nicht. Das musst du mir jetzt einfach mal glauben.
Es gibt aber auch andere mögliche Gründe. Vielleicht arbeite ich anders mit dem Programm als du. So Sachen wie "IMAP POP3", "HTML / Textmails" oder "viele Anhänge / wenig Anhänge" ... Wenn du raus bekommst warum der Fehler bei dir, aber nicht bei mir auftritt hast du ihn wahrscheinlich auch schon so gut wie behoben. Aber stell dir vor, es gibt keine Weltverschwörung die dich mit schlechter Software ärgern möchte. Bis auf das Problem mit dem "mehrere Seiten eines PDFs auf eine Seite drucken" kann ich deine Probleme nicht nachvollziehen. Vielleicht verstehst du jetzt, dass ich deine Aussage, das Gnome "sehr kaputt" ist, für einfach falsch halte. Aber du scheinst es ja auch zu benutzen, also kann es ja nicht so schlimm sein. Oder wirst du gezwungen(Unternehmenspolitisch oder so)?
> Dieser ist immer noch sehr kaputt und kaum zu benutzen.
Ich benutze ihn jeden Tag und finde es nicht so schlimm.
> Drucken funktioniert immer noch nicht gescheit. Ich drucke auf mehreren Druckern hier im Netz und es kommt immer so raus wie ich es mir vorgestellt habe. Was will man mehr.
> Evolution stürzt weiterhin immer ab und macht den Email Index kaputt (desynchronisiert). Ich hab hier mehr al 21.000 E-Mail und es arbeitet ohne Probleme.
> Es scheint keinerlei vernüftige Abstraktionsschichten zu geben, da die Tools teilweise direkt die DBUS, HAL oder GStreamer Bibliotheken aufrufen. Warum willst du für Abstraktionsschichten noch eine Schicht dazwischen bauen? Warum heißt den z.B. HAL "Hardware Abstraction Layer"?
> bei GNOME weiss man, dass sich die Abhängigkeiten gerade wegen dem Fehlen dieser Abstraktionsschicht wie Krakenarme überall hineinvertiefen. Aber selbst wenn ich noch eine Schicht dazwischenpacke, die Abhängigkeiten bleiben doch da. Ansonsten fehlt halt die Funktionalität.
> Warum willst du für Abstraktionsschichten noch eine Schicht dazwischen bauen? Warum heißt den z.B. HAL "Hardware Abstraction Layer"?
Das macht das FreeDesktop HAL doch gerade - doppelte Abstraktion. Diese Abstraktionsschicht befindet sich bereits im Linux Kernel, im BSD Kernel usw. Wozu nochmal eine draufpacken ? Wenn so etwas benötigt wird, dann sollte man es Desktopseitig korrekt in den GNOME libs mit reinpacken. Aber nicht ein komplettes Betriebssystem davon abhängig machen. Neuerdings benutzt alles irgendwie die libHAL der FreeDesktop ohne sich Gedanken dazu zu machen, ob man es nicht hätte besser Desktopseitig lösen können. Oder anders - jedenfalls korrekter - doch nicht als daemon.
Was gemeint war: eine weitere Abstraktionsschicht vor HAL bringt den Vorteil, dass Systeme, die kein HAL nutzen, ebenfalls angesprochen werden können, da die weitere Abstraktionsschicht diese ansprechen könnte. Das erleichtert die Portierung.
Aus der BSD und Solaris Welt hört man gegenteiliges. Nach Einführung von DBUS und HAL war (und ist es sicherlich noch) ein riesiges Problem entstanden.
Hast du da mal einen Link? Das neue Bibliotheken auf anderen Plattformen auch angepasst werden müssen ist klar. Aber da gerade Sun einige Gnome-Entwickler beschäftigt würde es mich wundern wenn es da riesige Probleme gibt.
... ich werde alle Chats aus dem IRC und private Emails mit Anwendern und Entwicklern gerne öffentlich mit jedem Wort verlinkt für dich ins Netz stellen ...
KDE macht dies sehr gut vor, indem sie DBUS und HAL in einer Abstraktionsschicht packen und die Anwendungen darauf zugreifen lassen. Hier vergisst du, dass KDE einen eigenen Dienst für die Interprozesskommunikation verwendet, nämlich DCOP. Kann man KDE auch ohne DCOP verwenden?
Doch, aber lies doch mal bitte nach: Soest: KDE macht dies sehr gut vor, indem sie DBUS und HAL in einer Abstraktionsschicht packen (Man beachte das "und".)
fuffy: Kann man KDE auch ohne DCOP verwenden? Soest: Kann ein Mensch ohne Herz leben ? (Es geht hier im weiteren Verlauf also um D-Bus.)
Ich: Und wenn KDE, wie du sagst, nicht ohne DCOP leben kann was bringt dann die Abstraktion? Du: Du kennst offensichtlich nicht den unterschied zwischen einer hal und einem ipc. Das ist schade.
Es geht hier also gar nicht um HAL dein Kommentar geht also komplett am Thema vorbei. Das finde ich jetzt schade.
Von Ikone des guten Geschmacks am Sa, 21. April 2007 um 23:07 #
Schon wieder eine Erfolgsmeldung zu GNOME auf mobilen Geräten. Ein fantastischer Desktop auf einer soliden Basis macht sowas eben möglich. Glückwunsch GNOME Projekt!
Von Ikone des guten Geschmacks am So, 22. April 2007 um 12:57 #
Bei Slashdot postet immer so ein Schlaukopf "BSD is dying". Soll ich das deshalb jetzt glauben? Wenn ich bei Slashdot schon nicht solchen "Experten" Glauben schenke, warum sollte ich das dann bei pro-linux. ...aber vielleicht bist du noch nicht so lange im Zwischennetz untwerwegs und nimmst jeden Kommentar fuer bare Muenze? Dann sei dir hiermit verziehen.
Was für ein Schwachsinn, Gnome ist überhaupt nicht für embedded Devices geeignet. Alleine schon wegen seiner vielen Softwareschichten. Im Moment muss man klar QTopia den Vorzug geben.
Aus dem Original:
Following GNOME's highly successful licensing strategy, the GNOME Mobile & Embedded Platform is distributed under the terms of the LGPL, which allows for royalty-free use in proprietary software products, but encourages contribution of platform code changes back to the community. This, combined with a thriving open development process supported by industry and community, makes the GMAE Platform uniquely suited to the needs of mobile and embedded developers.
Also was denn nun? Alles oder der größte Teil?
lg
Erik
lg
Erik
Dieser ist immer noch sehr kaputt und kaum zu benutzen. Drucken funktioniert immer noch nicht gescheit. Ich kann immer noch keine PDF's mit mehreren Seiten auf einem Blatt Papier ausdrucken. Evolution stürzt weiterhin immer ab und macht den Email Index kaputt (desynchronisiert). Auch druckt GThumb weiterhin nur schwaze GIF Bilder aus. Die Abhängigkeiten zu HAL sollte man wieder sauberst entfernen.
Auch kann bei GNOME von keiner sauberen Integration die Rede sein (ich komme beruflich aus dem Integrationsumfeld). Es scheint keinerlei vernüftige Abstraktionsschichten zu geben, da die Tools teilweise direkt die DBUS, HAL oder GStreamer Bibliotheken aufrufen. Man fragt sich manchmal wozu Evolution wohl HAL brauchen könnte. Wenn, dann sollte man sowas in einer GNOME spezifischen Bibliothek unterbringen und die Anwendungen darauf zugreifen lassen.
KDE macht dies sehr gut vor, indem sie DBUS und HAL in einer Abstraktionsschicht packen und die Anwendungen darauf zugreifen lassen. Sollte man kein DBUS und HAL haben, so kümmert sich diese Abstraktionsschicht um weiteres und erlaubt, dass die Anwendungen weiterhin "Baubar" bleiben. Dies ist bein GNOME leider unmöglich, da wohl jedes dem Desktop zuzuordnenden Tools das wohl selber irgendwie hineinbastelt.
Es sind keine klaren Zielvorgaben zu erkennen, auch ist keine saubere Integration auszumachen. Bei KDE kann man davon ausgehen, dass das Grundsystem gut abstrahiert wird und die Applikationen auf diese Abstraktionsschicht zugreifen, bei GNOME weiss man, dass sich die Abhängigkeiten gerade wegen dem Fehlen dieser Abstraktionsschicht wie Krakenarme überall hineinvertiefen.
Bitte keine "nimm Ubuntu" Antworten, da dies nicht meine Kernaussage betrifft.
Im Gegensatz zu KDE ist GNOME besser teil- und wiederverwendbar. Sugar (100$ Laptop) und GMEI (OpenMoko,Maemo) sind in gewissem Sinne genauso Gnome wie der Desktop von Ubuntu. Dass der Hauptfokus der Desktop ist, ist nicht so ganz klar.
KDE kann man gut ohne das alles benutzen - wie ist das mit gnome?
Und das gnome ein Problem mit sauberer Aufteilung hat, ist auch bekannt. Mehrere libs, die die gleichen Funktionen beinhalten - bekanntes 'feature'.
Bevor sich gnome auf den Mobilmarkt traut, sollten sie vielleicht erstmal aufräumen - dann wird hoffentlich auch der Speicherhunger etwas reduziert.
In KDE ist DCOP notwendig. Statt der HAL-Abstraktionsschicht werden direkt irgendwelche Systemspezifische Routinen verwendet. Was ist an Phonon besser als GStreamer?
Gibts hierzu irgendwelche repräsentativen Referenzen und Umfragen ?
Weil's das vieleicht NICHT bei BSD, Darwin, Windows etc. gibt ? Wenn's vorher vernünftig abstrahiert wurde, so könnte man der Abstraktionsschicht mitteilen "auf dieser Plattform nicht" und voila die Apps und was dazu gehört kann man dennoch compilieren ?
Wenn es Bibliotheken, die ein Programm braucht auf einer anderen Plattform nicht gibt muss man sie halt portieren. Das müsste man auch mit einer Abstraktionsschicht machen.
> Wenn es Bibliotheken, die ein Programm braucht auf einer anderen Plattform
> nicht gibt muss man sie halt portieren.
D.h. du portierst z.B. eine Bibliothek zum Font-Rendering auf die Zielplattform, obwohl es die Funktionalität dort schon gibt (Windows und Mac OS X können Schriften darstellen, habe ich gehört).
- Damit vergrößerst du den Binärklumpen, den jemand installieren muss, um deine Anwendung laufen zu lassen.
- Du erhöhst den Speicherverbrauch und senkst die Startgeschwindigkeit deiner Anwendung.
- Du führst eine zweite, parallele Konfiguration der Schriftarten ein, die entweder inkonsistent mit der nativen ist oder von dir aktiv konsistent gehalten werden muss.
- Du wirfst den Vorteil weg, die ausgetestete Bibliothek der Zielplattform für deine Zwecke einzuspannen. Das bedeutet mehr Bugs für deine Nutzer.
- Wenn die Bibliothek nicht zufällig von dir gewartet wird (lies: oder deinem Team), dann hast du keinen Einfluss darauf, ob und wann die Portierung stattfindet. Oder du musst dich dort engagieren und dich in fremden Kode einarbeiten. Aber eigentlich wolltest du doch nur die Software, die dir schon vertraut ist und die dir am Herzen liegt (oder für die du bezahlt wirst (oder beides, das soll es geben), auf einer neuen Plattform anbieten können. Für diese Software bleibt dann entsprechend weniger Zeit.
Du anwortest, "Na, dann implementiere ich die Portierung eben so, dass sie die native Funktionalität benutzt."? In dem Moment hättest du die äußere Schnittstelle der Bibliothek zur Abstraktionsschnittstelle erhoben. Die ist dann aber vermutlich weit weniger sauber und elegant, als wenn man sie gleich mit diesem Ziel entworfen hätte.
> Das müsste man auch mit einer Abstraktionsschicht machen.
Ja, aber eine solche Schicht sollte so entworfen sein, dass sie dünn ist. Sie passt nur Vorhandenes an die definierte Schnittstelle an, statt das Rad komplett neu zu erfinden.
>> Das müsste man auch mit einer Abstraktionsschicht machen.
> Ja, aber eine solche Schicht sollte so entworfen sein, dass sie dünn ist. Sie passt nur Vorhandenes an die definierte Schnittstelle an, statt das Rad komplett neu zu erfinden.
Und was ist wenn es in der Basisschicht nicht alle Funktionen gibt? Diese Fehler enthalten oder Funktionen einfach anders Interpretiert werden oder sie sich ändert...
Warum willst du eigentlich überhaupt Plattformunabhängigkeit?
http://fun.barnal.de/videos/fresse_halten.mpeg
> basieren und somit nicht mehr frei sind? Du willst allen ernstes dich von Colsed-Source abhängig machen?
Wow, an anderer Stelle beschwerst du dich über die Diskussionkultur eines
Posters, und hier kommst du mit solchen dümmlichen Unterstellungen.
Von "basieren" kann keine Rede sein. Die Abstraktionsschicht sorgt ja
gerade dafür, dass die OpenSource-Anwendung sich nicht von MS abhängig macht.
Es wird dich erschrecken zu hören, aber jede OpenSource-Anwendung, die unter Windows läuft,
benutzt direkt oder indirekt ClosedSource und ist nach deiner Definition nicht frei.
Übrigens hat die GPL kein Problem mit dem Linken von Freier Software gegen
Basisbibliotheken des Betriebssystems.
Außerdem: Wir reden von einem Port auf eine andere Zielplattform.
Warum sollte meine Version unter Linux unfrei werden, nur weil es auch eine
Windowsversion davon gibt und jemand eine Implementierung einer Schnittstelle geschrieben hat,
die gegen die CSS-Plattformbibliotheken linkt?
> Und was ist wenn es in der Basisschicht nicht alle Funktionen gibt?
Die grundlegenden Probleme wie Hardwareerkennung oder Schriftdarstellung sollten
auf den verbreiteten Plattformen zufriedenstellend gelöst sein, wenn nicht
sogar besser als unter Linux / BSD / ... (z.B. wegen der besseren Verfügbakeit von Treibern)
Sollte das aber wirklich der Fall sein, dann ist eben mehr Arbeit gefragt
und die Implementierung der Schnittstelle auf dieser Plattform wird dicker.
Das ist immer noch weniger Arbeit und resultierender Ballast als bei Null anzufangen.
> Diese Fehler enthalten
Dann hat die Zielplattform einen Bug.
Wenn die Systembibliotheken gravierende Fehler enthalten, sollte sie der Hersteller fixen, oder?
Ach, ich vergaß, MS mag seine Nutzer ja nicht und fixt keine Bugs.
Umso besser, haben sie einen Grund mehr, auf ein freies Betriebssystem zu wechseln.
Das ist doch in deinem Sinne.
> oder Funktionen einfach anders Interpretiert werden
Tut mir leid, ich weiß nicht, was du hier sagen willst.
> oder sie sich ändert...
Das ist genau der Fall, bei der die Abstraktionsschicht punkten kann.
Du änderst die Implementierung der Schnittstelle, und die ganzen Anwendungen,
die gegen die Schnittstelle geschrieben sind, bekommen davon nichts mit.
Außerdem kann man MS wohl kaum Vernachlässigung der Rückwärtskompatibilität
ihrer Betriebssysteme vorwerfen. Eher im Gegenteil, dass sie deswegen
in der Vergangenheit zu viele Kompromisse gemacht haben.
Siehe z.B. die zögerliche Einführung von Multinutzer und deren Rechten.
Also ich benutze ihn erfolgreich, und das seit Jahren. Was also soll denn so kaputt und schwer benutzbar sein?
Evolution? Habe ich... nutze ich... knapp 18.000 Mails im Archiv und arbeitet flott und stabil.
Drucken? Geht auch wunderbar. Mag aber auch am Drucker liegen, dass er sich so bereitwillg hat einbinden lassen.
Integration? Top kann ich da nur sagen. Was ich in Evolution verwalte steht mir in vielen Anwendungen und af dem Desktop zur Verfügung.
Du bist scheinbar nur ein weiterer gelangweilter GNOME Basher und KDE Troll... dann nutz doch weiter KDE aber red nicht über Dinge von denen du nichts verstehst und alle sind glücklich. Braucht dein Ego diese Provokation? Hechelst du nach dieser Aufmerksamkeit?
Ich arbeite erfolgreich und problemlos mit dem GNOME Desktop. DAS ist der Punkt. Es funktioniert einfach einfach.
Warum benutzt du nichtmal google? Evolutionabstürze sind nun wirklich ein bekanntes Problem.
http://bugzilla.gnome.org/show_bug.cgi?id=213072
Nur ein Beispiel.
Ausserdem ist es nicht "ein bug" sondern es ist hier sehr ein kritischer Bug der nie wirklich beseitigt wurde. Solltest das mal lesen bevor du darauf antwortest. Nun will man ernsthaft das Evolution Data Server (genau da wo der Bug anzunehmen sei) auf portable Plattformen portieren ?
Und das die genannten Probleme bei auftreten, bedeutet noch lange nicht, dass GNOME sehr kaputt ist und auf keinem Rechner läuft. Es sagt einzig und allein nur eines aus: bei Dir funktioniert es nicht. Nicht mehr und nicht weniger. Und kann wohl kaum als Maßstab für alle GNOME-Installationen herhalten.
Was war denn daran nicht sachlich ?
> Natürlich ist GNOME nicht völlig fehlerfrei, aber welche Software ist das schon?
Hier differenziert man zwischen "nicht vollig fehlerfrei" (trifft nicht auf GNOME zu) und "vollkommen kaputt" (trifft auf GNOME zu). Fehler hat jede Software, nur die Anhäufung der Fehler in der Grundfunktionalität (ohne jetzt die weiteren Funktionalitäten zu betrachten) ist bei GNOME sehr hoch.
> Und kann wohl kaum als Maßstab für alle GNOME-Installationen herhalten.
Es geht hier nicht um GNOME-Installationen, sondern um das was man Programmcode nennt. Wenn der GNOME Code schon schlecht ist (und ich weiss das), dann kannste es installieren wo immer man möchte. Der Code bleibt schlecht. Der Vorteil den man vieleicht haben könnte ist, dass gewiefte Distributionsanbieter einige Codemonkeys irgendwo sitzen haben, die diese Bugs nach und nach rausbasteln.
Ich gehe jetzt mal auf dein Originalbeitrag ein, den du am Sa, 21. Apr 2007 um 8:55 geschrieben hast.
1. Übertreibungen, wenn du wirklich sachlich sein willst solltest du Übertreibungen nicht verwenden.
Beispiel:
"GNOME wieder einmal etliche Initiativen ankündigt"
GNOME hat nur eine Initiative ankündigt, also warum etliche?
2. Nachweislich falsche Behauptungen:
Beispiel:
"... weiterhin "Baubar" bleiben. Dies ist bein GNOME leider unmöglich ..."
Das GNOME "Baubar" ist doch alleine schon damit bewiesen das ich es gerade benutzen. Also muss es ja möglich sein.
Schau mal in deinen Text ob du noch mehr Textstellen findest die unsachlich seien könnten. Wenn du keine weiteren findest bin ich dir auch gerne noch mal behilflich.
>> Natürlich ist GNOME nicht völlig fehlerfrei, aber welche Software ist das schon?
> Hier differenziert man zwischen "nicht vollig fehlerfrei" (trifft nicht auf GNOME zu) und "vollkommen kaputt" (trifft auf GNOME zu). Fehler hat jede Software, nur die Anhäufung der Fehler in der Grundfunktionalität (ohne jetzt die weiteren Funktionalitäten zu betrachten) ist bei GNOME sehr hoch.
Das "vollkommen kaputt" habe ich oben in der Liste noch nicht ist aber ersten keine sehr sachliche und konstruktive aussage und zweitens stimmt es zumindest für meine Installation nicht zu.
>> Und kann wohl kaum als Maßstab für alle GNOME-Installationen herhalten.
> Es geht hier nicht um GNOME-Installationen, sondern um das was man Programmcode nennt. Wenn der GNOME Code schon schlecht ist (und ich weiss das), dann kannste es installieren wo immer man möchte. Der Code bleibt schlecht. Der Vorteil den man vieleicht haben könnte ist, dass gewiefte Distributionsanbieter einige Codemonkeys irgendwo sitzen haben, die diese Bugs nach und nach rausbasteln.
Killerargumente wie diese solltest du in einer sachlichen Diskussion auch meiden. Ich habe jetzt keine Möglichkeit dies zu widerlegen, zumindest nicht ohne auch ein Killerargument anzuwenden. Aber ich versuche es trotzdem einmal.
Du schreibst, "Es geht hier nicht um GNOME-Installationen, sondern um das was man Programmcode nennt." Ich würde bei der Qualität von Programmen dort keinen zwingenden unterschied machen. Oder möchtest du behaupten das ein Compilat besser als sein Quellcode sein kann?
Und weiter schreibst du, "... gewiefte Distributionsanbieter einige Codemonkeys irgendwo sitzen haben ..." glaubst du den wirklich, das die Distributionen die Bugs, die sie raus machen nicht in das Basisprojekt zurückfließen?
Ich habe von dem Quellcode keine Analyse gemacht, das währe wahrscheinlich auch ein Projekt von mehreren Jahren. Was ich allerdings sagen kann ist das ich schon seit 2002 Evolution benutze das unter SuSE, Debian und jetzt Ubuntu. Meine älteste Mail die ich gerade finden konnte ist vom 04 May 2002 15:24:05 +0200, geschrieben mit Ximian Evolution 1.0.3. Ich hatte seitdem unter Gnome und Evolution keine Datenverluste, was ich vorher mit
KMail Version 1.3 schon hatte. (Ich denke KDE ist seit dem aber auch besser geworden.)
Aber ich glaube du hast recht. Die Distributionen haben alle Programmierer, die nichts besseres zu tun haben und die Fehler für mich raus zu machen und bei dir wider rein.
Das hat nichts mit Argumenten oder Sachlichkeit zu tun, sondern ganz einfach damit, dass ich diese Art der Konversation schon seit Jahren kenne und sie am Ende zu nichts führt. Man dreht sich permanent im Kreis und kommt mit dem was man aussagen möchte nicht weiter. Es kommt eine Aussage zur Nächsten und am Ende verliert man jegliche Übersicht zu dem was man eigentlich Aussagen möchte.
Wir sind uns doch alle einige und auch klar darüber das GNOME überall Fehler hat. Gut, es gibt nichts was keine Fehler hat, nur stellt sich meiner Ansicht nach es so dar, dass bei GNOME die Anzahl der Fehler einfach zu hoch ist, um damit gescheit zu arbeiten.
Jetzt kommt natürlich wieder die Argumentation, das aussgerechnet bei dir natürlich seit jahrzehnten alles ohne jeglichen Absturz und ohne jegliche Probleme alles einwandfrei und super lief. Wie kann das aber sein, da wir uns doch einige sind das GNOME nicht frei von Fehlern sein kann. Einer von uns muss demnach ja nicht die Wahrheit sagen. Nur weil ich diese ganzen Fehler auf dem Punkt bringe und behaupte das GNOME kaputt ist, so fühlst du dich auf den Schlipps getreten und startest hier eine "Quarschkonversation". Du hast einfach keinen Plan von dem, was du da sagst und willst hier nur Personen und User dumm darstehen lassen. Ist klar natürlich mein Fehler das GNOME nicht funktioniert.
Meine Güte....
Das genau das Problem bei Open Source... Einfach zu viele Egos und Alteregos die zuviel Politik in die Runde werfen. Ich habe im Eingang klar erwähnt, was die Probleme sind. Für mich bestehen diese Probleme weiterhin. Auch zu dem einen Link zum Evolution Bug (der seit 6 Jahren bekannt ist, aber natürlich in genau deiner Evolution Version nie auftrat) trat leider bei etlichen anderen Usern auf. Genau Heute habe ich zu diesem Bug wieder 2 Mails erhalten.
> Wir sind uns doch alle einige und auch klar darüber das GNOME überall Fehler hat.
Genau das sind wir ja nicht. Wir können und darauf einigen das Gnome Fehler hat. Und auch darauf, das jeder Fehler ein Fehler zuviel ist. Und auch das ein Bugreport 6 Jahre offen bleibt ist eindeutig zuviel. Dies zeigt aber auch, das dieser Fehler wohl auch bei den Entwicklern nicht auftritt. Denn das weiß ich aus eigener Erfahrung, dass Fehler die die Entwickler selber stören sehr schnell verschwinden.
Warum tritt der Fehler also nicht bei mir auf aber bei dir?
Deine These ist also alle die mit Gnome/Evolution ohne Probleme arbeiten lügen.
Warum sollte ich das machen? Ich verdiene mein Geld nicht mit Gnome oder Linux hab also keine finanziellen Vorteile. Wenn mich so ein Fehler so nerven würde würde ich zu einem anderen E-Mail Programm wechseln. Es gibt ja gute andere für Linux.
Also ich lüge nicht. Das musst du mir jetzt einfach mal glauben.
Es gibt aber auch andere mögliche Gründe. Vielleicht arbeite ich anders mit dem Programm als du. So Sachen wie "IMAP POP3", "HTML / Textmails" oder "viele Anhänge / wenig Anhänge" ...
Wenn du raus bekommst warum der Fehler bei dir, aber nicht bei mir auftritt hast du ihn wahrscheinlich auch schon so gut wie behoben.
Aber stell dir vor, es gibt keine Weltverschwörung die dich mit schlechter Software ärgern möchte. Bis auf das Problem mit dem "mehrere Seiten eines PDFs auf eine Seite drucken" kann ich deine Probleme nicht nachvollziehen. Vielleicht verstehst du jetzt, dass ich deine Aussage, das Gnome "sehr kaputt" ist, für einfach falsch halte.
Aber du scheinst es ja auch zu benutzen, also kann es ja nicht so schlimm sein. Oder wirst du gezwungen(Unternehmenspolitisch oder so)?
Ich benutze ihn jeden Tag und finde es nicht so schlimm.
> Drucken funktioniert immer noch nicht gescheit.
Ich drucke auf mehreren Druckern hier im Netz und es kommt immer so raus wie ich es mir vorgestellt habe. Was will man mehr.
> Evolution stürzt weiterhin immer ab und macht den Email Index kaputt (desynchronisiert).
Ich hab hier mehr al 21.000 E-Mail und es arbeitet ohne Probleme.
> Es scheint keinerlei vernüftige Abstraktionsschichten zu geben, da die Tools teilweise direkt die DBUS, HAL oder GStreamer Bibliotheken aufrufen.
Warum willst du für Abstraktionsschichten noch eine Schicht dazwischen bauen? Warum heißt den z.B. HAL "Hardware Abstraction Layer"?
> bei GNOME weiss man, dass sich die Abhängigkeiten gerade wegen dem Fehlen dieser Abstraktionsschicht wie Krakenarme überall hineinvertiefen.
Aber selbst wenn ich noch eine Schicht dazwischenpacke, die Abhängigkeiten bleiben doch da. Ansonsten fehlt halt die Funktionalität.
Das macht das FreeDesktop HAL doch gerade - doppelte Abstraktion. Diese Abstraktionsschicht befindet sich bereits im Linux Kernel, im BSD Kernel usw. Wozu nochmal eine draufpacken ? Wenn so etwas benötigt wird, dann sollte man es Desktopseitig korrekt in den GNOME libs mit reinpacken. Aber nicht ein komplettes Betriebssystem davon abhängig machen. Neuerdings benutzt alles irgendwie die libHAL der FreeDesktop ohne sich Gedanken dazu zu machen, ob man es nicht hätte besser Desktopseitig lösen können. Oder anders - jedenfalls korrekter - doch nicht als daemon.
Aus der BSD und Solaris Welt hört man gegenteiliges. Nach Einführung von DBUS und HAL war (und ist es sicherlich noch) ein riesiges Problem entstanden.
Hier vergisst du, dass KDE einen eigenen Dienst für die Interprozesskommunikation verwendet, nämlich DCOP. Kann man KDE auch ohne DCOP verwenden?
Kann ein Mensch ohne Herz leben ?
Das ist schade.
Soest: KDE macht dies sehr gut vor, indem sie DBUS und HAL in einer Abstraktionsschicht packen
(Man beachte das "und".)
fuffy: Kann man KDE auch ohne DCOP verwenden?
Soest: Kann ein Mensch ohne Herz leben ?
(Es geht hier im weiteren Verlauf also um D-Bus.)
Ich: Und wenn KDE, wie du sagst, nicht ohne DCOP leben kann was bringt dann die Abstraktion?
Du: Du kennst offensichtlich nicht den unterschied zwischen einer hal und einem ipc. Das ist schade.
Es geht hier also gar nicht um HAL dein Kommentar geht also komplett am Thema vorbei. Das finde ich jetzt schade.
Ach gar nichts?
Wußte ich doch....
>
> Ach gar nichts?
>
> Wußte ich doch....
Warum Fragst du das jetzt? Es hat doch niemand behauptet das es was miteinander zu tun hat.
Glückwunsch GNOME Projekt!
Ebend dies ist nicht der Fall. Ab und zu mal die Threads durchlesen.
Wenn ich bei Slashdot schon nicht solchen "Experten" Glauben schenke, warum sollte ich das dann bei pro-linux.
...aber vielleicht bist du noch nicht so lange im Zwischennetz untwerwegs und nimmst jeden Kommentar fuer bare Muenze? Dann sei dir hiermit verziehen.
Und warum sollten wir Dir glauben ?
Eine der dümmsten Antworten
Gehts eigentlich noch blöder?