Ja das sieht wirklich nett aus. Sowas ähnliches hatte ich mal für die KDE-Leiste, aber das hier ist vieeeel schöner. Sieht fast so aus wie ein "Window-Maker" (???) Miniprogramm.
Und dafür brauchts keine sauteure Sparc-Maschine, ein stinknormaler Athlon64 tuts auch. Blöd ist nur, dass man es nich transparent über alle Fenster legen kann, bzw. ich noch nicht herausgefunden habe, wie (Composite ist an). Die Applets sind ja keine "richtigen" eigenen Windows, sonst könnte man ja einfach mit xmod an ihnen drehen.
Was hat das bitte mit Sparcmaschinen zu tun? Ich verstehe den Vergleich nicht wirklich. IMHO sind Sparcmaschinen nicht primär für den Clienteinsatz gebaut, sondern werden meistens da plaziert wo hohe I/O Leistung und Zuverlässigkeit benötigt wird. Soviel zum Thema Sparc.
>Es waren offenbar recht viele Patches dafür notwendig.
Wie ist das zu verstehen. Heißt es, dass es in dem KDE Code jetzt vermehrt Stellen gibt die nur für Solaris nötig sind? Also mit #ifdef und solchen sachen? Ich weiß nicht ob das dann so gut ist, sowas bläst den Code doch ganzschön auf. Hätte man es nicht einfach mit dem gcc für Solaris Übersetzen können, damit scheint es ja auch ohne patches zu funktionieren.
> Hätte man es nicht einfach mit dem gcc für Solaris > Übersetzen können, damit scheint es ja auch ohne > patches zu funktionieren.
Nein, hätte man nicht, weil der g++ weder zur vom Hersteller der Plattform verbindlich diktierten ABI noch zu sich selbst kompatibel ist. Der g++ wechselt seine ABI alle 24 Monate. In der Linux-Welt lässt man sich das bieten, weil man sich damit abgefunden hat und weil es keine Alternative gibt, aber nicht anderswo. Jedes neue Solaris ist eine binärkompatible Erweiterung seines Vorgängers, da passt kein g++ rein.
Kleiner Nachtrag, bevor sich jemand über die "verbindlich diktierten" Standards beschwert und auf eine falsche Definition von "Freiheit" und "Vielfalt" hinweist (weil es sowieso kommen wird):
Bei Mozilla ist es ja auch kein Mangel an "Freiheit" und "Vielfalt", dass der Browser sich an die verbindlich vom W3C diktierten Standards hält und defekte JPEGs einfach nicht anzeigt, sondern ein Feature, über das sich der Browser definiert. Es geht um Konformität und Kompatibilität, diese bietet der g++ leider nach wie vor nicht, darüber täuscht auch seine "Freiheit" nicht hinweg, von der kann man sich nämlich keine kompatiblen Binaries kaufen.
wenn ich den beitrag oben richtig gelesen habe konnte man KDE auf solaris bereits mit dem g++ kompilieren. Die Frage ist also eine andere als die die du versuchst zu beantworten.
Tatsache scheint zu sein: - KDE wird mit dem g++ entwickelt und lässt sich mit diesem auch auf allen GNU und BSD Systemen übersetzen. - Für Solaris scheint es den g++ zu geben und damit lässt sich auch KDE auf Solaris übersetzen
Frage: Warum sollte man dann Änderungen in KDE vornehmen um es auch mit dem "Solaris-Kompiler" zu übersetzen. Das einzige was KDE dadurch gewinnt ist ein aufgeblasener KDE Code.
Das heisst, dass KDE dadurch deutlich schneller auf Solaris laufen sollte, als ein mit dem g++ kompiliertes Solaris.
Tests mit Mozilla unter g++ bzw. Sun One (oder Forte wie es vorher hiess) bei uns in der Firma haben gezeigt, dass es mind. 20% schneller und deutlich stabiler lief (das ganze allerdings unter Solaris 8).
So ist das halt mit den VSAs. Das LF ist zwar in der Regel kein großes Thema, aber sobald ein Compiler plattformunabhägig ist, wird der Aufwand sowas zu unterstützen recht hoch. Theoretisch wäre es sinnvoll nurnoch auf NVSAs zu setzen. Leider hat sich da noch nicht wirklich brauhbares durchgesetzt. Bei C ist das bisher zwar einigermasen gelungen, aber was C++ betrifft braut leider jeder sein eigenes Süppchen. Man hat zwar versucht mit O3 einiges zu erreichen (was seit gcc 3.4 auch ganz brauchbar ist), aber leider gibt es dabei einige unklare Definitionen im NM und die Behandlung von NVDs ist bei vielen Compilern ebenfalls anders. Aufgrund der Bestrebungen einiger Hersteller ihre VSAs auf biegen und brechen kompatibel zu halten wird sich daran leider nicht viel ändern.
>Jedes neue Solaris ist eine binärkompatible Erweiterung seines Vorgängers, da passt kein g++ rein. ---
Ist doch nicht dein ernst -oder? Eine Binärkompatibilität ist wegen Ermangelung des SourceCodes für ein Closed Source/OS ja wohl auch essenziell. Im gegensatz ist eine Binärkompatibilität bei einem Open Source/OS aber eben nicht mehr von so essenzieller bedeutung.
Zudem ist es ja wohl unsinn sugerieren zu wollen, dass man ein Entwicklungssystem "einfach so" gegen ein anderes austauschen kann. Selbst (oder gerade) wenn die Entwicklungssysteme "nur" CS sind.
> Eine Binärkompatibilität ist wegen Ermangelung des SourceCodes für ein > Closed Source/OS ja wohl auch essenziell.
Da hast Du Recht.
> Im gegensatz ist eine Binärkompatibilität bei einem Open Source/OS aber eben nicht > mehr von so essenzieller bedeutung.
Wieder richtig. Es geht auch ohne Binärkompatibilität. Allerdings nur mehr schlecht als recht.
Es begrenzt Linux auf eine Nische, denn außerhalb der Welt von Leuten, die bereit sind, für ihre Religion, äh ihr Betriebssystem viele Wochenenden und Nächte zu opfern, ist Binärinkompatibilität nicht akzeptabel.
Leider (oder je nach Standpunkt glücklicherweise) ist es das Wesen einer jeden Religion, dass man Sachargumenten, die dem eignen Dogma widersprechen, kein Gehör schenkt. Da wird mal schnell ein offensichtlicher Mangel in einen Vorteil umgemünzt. Denn unter Systemen wie Solaris und Windows habe ich nicht nur Binär-, sondern auch Quellcodekompatibilität. Unter Linux kann ich mich nicht mal drauf verlassen, dass der Name für ein Device sich nicht von einer Distributionsversion zur nächsten ändert. In einem solchen Falle hilft übrigens auch Neuübersetzen nichts. Da muss der Entwickler schon mehr Aufwand betreiben (den er nur betreiben kann, da er eh in seiner unbezahlten Freizeit zum Spaß werkelt).
> Wieder richtig. Es geht auch ohne Binärkompatibilität. Allerdings nur mehr schlecht als recht.
Binärkompatibilität ist bei OS schlichtweg nicht notwendig. Das Prinzip Binaries zu installieren liegt doch noch in der Tradition des CS und sollte einmal grundsätzlich in Frage gestellt werden. Zudem wurden Fortschritte beim GCC nur deshalb möglich, weil die Abwärtskompabilität aufgegeben wurde. Wir profitieren alle davon.
> Das Prinzip Binaries zu installieren liegt doch noch in der Tradition des CS > und sollte einmal grundsätzlich in Frage gestellt werden.
Prinzipiell darf man alles in Frage stellen. Nur sollte man am Ende zu einer sachlich begründeten Antwort kommen. Und der Zustand der geradezu traditionellen Binärinkompatibilität unter Linux ist ein Hemmschuh. Warum sollte ein System darunter leiden, wenn es nicht nur Sourcecodekompatibilität bietet, sondern zusätzlich auch Binärkompatibilität?
Der jetzige Zustand ist der, dass nichtmal die Binaries einer Distribution über verschiedene Versionen hinweg binärkompatibel sind. Das mag für Leute mit viel Zeit und dem Wunsch, Detailwissen über ihr System zu erwerben, akzeptabel sein. Für die große Masse, die einen Computer emotionslos als bloßes Werkzeug betrachten, ist es eine Katastrophe. Unter Systemen wie Windows nehme ich mir ein beliebiges Programm, installiere es per Setup.exe und es funktioniert. Unter W98 genauso wie unter WXP.
Es ist pure Ignoranz, dies als nicht erstebenswert zu deklarieren.
> Zudem wurden Fortschritte beim GCC nur deshalb möglich, weil die > Abwärtskompabilität aufgegeben wurde.
Dann war der gcc entweder früher so schlecht oder er ist jetzt viiiiieeeeel besser als die Konkurrenz ;-)
> Wir profitieren alle davon.
Du vielleicht. Ein paar Gentoo-Freaks vielleicht. Ein paar OSS-Entwickler vielleicht (denn es macht Arbeit, sein Programm für alle gcc-Versionen kompatibel zu halten). Kommerzielle Entwickler freuen sich darüber nicht. Und die meisten Nutzer auch nicht. Ach nein, die interessiert es nicht. Die benutzen eh Win oder Mac.
>Wieder richtig. Es geht auch ohne Binärkompatibilität. Allerdings nur mehr schlecht als recht. --- Bei welchen "Anwenderprogrammen" ohne KernelTreiber(!) hattest Du denn schon Probleme bezüglich der "Binärkompatibilität"? Hier sollte man wohl "absichtliche" Binärinkompatibilität die der Distributer aufgrund einer nicht offiziellen freigabe (zb gcc) raushalten. Gnu.Linux leidet (wenn überhaubt) doch wesentlich mehr unter einer mangelden Umsetzung der LSB als unter einer Binärinkompatibilität.
>Es begrenzt Linux auf eine Nische, denn außerhalb der Welt von Leuten, die bereit sind, für ihre Religion, äh ihr Betriebssystem viele Wochenenden und Nächte zu opfern, ist Binärinkompatibilität nicht akzeptabel. --- Für Entwickler wäre eine breitere LSB unterstützung imho viel sinniger als eine auf Teufel komm raus (um bei deinen Religions "Argumenten" zu bleiben) erreichte Binärkompatibilität.
>Leider (oder je nach Standpunkt glücklicherweise) ist es das Wesen einer jeden Religion,... --- Falsches Forum ?
>Denn unter Systemen wie Solaris und Windows habe ich nicht nur Binär-, sondern auch Quellcodekompatibilität. --- Und wieso laufen viele Windows9X,NT (X) Programme nicht und einige erst nach basteln unter WindowsXP? Wie sieht es mit Windows 3.11 Programmen aus?
>Unter Linux kann ich mich nicht mal drauf verlassen, dass der Name für ein Device sich nicht von einer Distributionsversion zur nächsten ändert. In einem solchen Falle hilft übrigens auch Neuübersetzen nichts. Da muss der Entwickler schon mehr Aufwand betreiben (den er nur betreiben kann, da er eh in seiner unbezahlten Freizeit zum Spaß werkelt). --- Wenn er "zum Spaß werkelt" wird er erkennen, dass sich ein "werkeln" lohnen würde und er wird es tun - oder eben nicht.
Oft sind Anpassungen an andere Compiler auch nur Ergänzungen im Code, weil der g++ da manchmal sehr nett ist und gewisse Sachen automatisch macht.
Der Solaris C++ Compiler ist zum Beispiel recht unbarmherzig was Doppeldeklaration von Variablen in verschiedenen Sichtbarkeitsbreichen betrifft. Also wenn man zB einen Parameter x und eine lokale Variable x hat. Ansich nicht falsch, aber vermutlich nicht gewollt, daher gibt es beim Solaris Compiler ein Warning.
Jergar
PS: Glückwunsch zur gelungenen Portierung
Sowas ähnliches hatte ich mal für die KDE-Leiste, aber das hier ist vieeeel schöner.
Sieht fast so aus wie ein "Window-Maker" (???) Miniprogramm.
Interessiert mich auch, wo man das bekommt.
Schöne Grüße
Mark
gruß mathes
IMHO sind Sparcmaschinen nicht primär für den Clienteinsatz gebaut, sondern werden meistens da plaziert wo hohe I/O Leistung und Zuverlässigkeit benötigt wird. Soviel zum Thema Sparc.
Der hat in seiner Freizeit großes Geleistet!
..on er wohl noch Zeit für andere Dinge hatte?
Wie ist das zu verstehen. Heißt es, dass es in dem KDE Code jetzt vermehrt Stellen gibt die nur für Solaris nötig sind? Also mit #ifdef und solchen sachen?
Ich weiß nicht ob das dann so gut ist, sowas bläst den Code doch ganzschön auf. Hätte man es nicht einfach mit dem gcc für Solaris Übersetzen können, damit scheint es ja auch ohne patches zu funktionieren.
> Übersetzen können, damit scheint es ja auch ohne
> patches zu funktionieren.
Nein, hätte man nicht, weil der g++ weder zur vom Hersteller der Plattform verbindlich diktierten ABI noch zu sich selbst kompatibel ist. Der g++ wechselt seine ABI alle 24 Monate. In der Linux-Welt lässt man sich das bieten, weil man sich damit abgefunden hat und weil es keine Alternative gibt, aber nicht anderswo. Jedes neue Solaris ist eine binärkompatible Erweiterung seines Vorgängers, da passt kein g++ rein.
Bei Mozilla ist es ja auch kein Mangel an "Freiheit" und "Vielfalt", dass der Browser sich an die verbindlich vom W3C diktierten Standards hält und defekte JPEGs einfach nicht anzeigt, sondern ein Feature, über das sich der Browser definiert. Es geht um Konformität und Kompatibilität, diese bietet der g++ leider nach wie vor nicht, darüber täuscht auch seine "Freiheit" nicht hinweg, von der kann man sich nämlich keine kompatiblen Binaries kaufen.
ac
Die Frage ist also eine andere als die die du versuchst zu beantworten.
Tatsache scheint zu sein:
- KDE wird mit dem g++ entwickelt und lässt sich mit diesem auch auf allen GNU und BSD Systemen übersetzen.
- Für Solaris scheint es den g++ zu geben und damit lässt sich auch KDE auf Solaris übersetzen
Frage: Warum sollte man dann Änderungen in KDE vornehmen um es auch mit dem "Solaris-Kompiler" zu übersetzen. Das einzige was KDE dadurch gewinnt ist ein aufgeblasener KDE Code.
Außerdem dürfte der SUN-CC besseren (optimierteren) Code für Sparc ausspucken, als der g++, der teilweise mit sparc Probleme hat.
Tests mit Mozilla unter g++ bzw. Sun One (oder Forte wie es vorher hiess) bei uns in der Firma haben gezeigt, dass es mind. 20% schneller und deutlich stabiler lief (das ganze allerdings unter Solaris 8).
Gruss
Theoretisch wäre es sinnvoll nurnoch auf NVSAs zu setzen. Leider hat sich da noch nicht wirklich brauhbares durchgesetzt.
Bei C ist das bisher zwar einigermasen gelungen, aber was C++ betrifft braut leider jeder sein eigenes Süppchen. Man hat zwar versucht mit O3 einiges zu erreichen (was seit gcc 3.4 auch ganz brauchbar ist), aber leider gibt es dabei einige unklare Definitionen im NM und die Behandlung von NVDs ist bei vielen Compilern ebenfalls anders.
Aufgrund der Bestrebungen einiger Hersteller ihre VSAs auf biegen und brechen kompatibel zu halten wird sich daran leider nicht viel ändern.
---
Ist doch nicht dein ernst -oder?
Eine Binärkompatibilität ist wegen Ermangelung des SourceCodes für ein Closed Source/OS ja wohl auch essenziell. Im gegensatz ist eine Binärkompatibilität bei einem Open Source/OS aber eben nicht mehr von so essenzieller bedeutung.
Zudem ist es ja wohl unsinn sugerieren zu wollen, dass man ein Entwicklungssystem "einfach so" gegen ein anderes austauschen kann. Selbst (oder gerade) wenn die Entwicklungssysteme "nur" CS sind.
mfg
Doch, das ist sein Ernst.
> Eine Binärkompatibilität ist wegen Ermangelung des SourceCodes für ein
> Closed Source/OS ja wohl auch essenziell.
Da hast Du Recht.
> Im gegensatz ist eine Binärkompatibilität bei einem Open Source/OS aber eben nicht
> mehr von so essenzieller bedeutung.
Wieder richtig. Es geht auch ohne Binärkompatibilität. Allerdings nur mehr schlecht als recht.
Es begrenzt Linux auf eine Nische, denn außerhalb der Welt von Leuten, die bereit sind, für ihre Religion, äh ihr Betriebssystem viele Wochenenden und Nächte zu opfern, ist Binärinkompatibilität nicht akzeptabel.
Leider (oder je nach Standpunkt glücklicherweise) ist es das Wesen einer jeden Religion, dass man Sachargumenten, die dem eignen Dogma widersprechen, kein Gehör schenkt. Da wird mal schnell ein offensichtlicher Mangel in einen Vorteil umgemünzt. Denn unter Systemen wie Solaris und Windows habe ich nicht nur Binär-, sondern auch Quellcodekompatibilität. Unter Linux kann ich mich nicht mal drauf verlassen, dass der Name für ein Device sich nicht von einer Distributionsversion zur nächsten ändert. In einem solchen Falle hilft übrigens auch Neuübersetzen nichts. Da muss der Entwickler schon mehr Aufwand betreiben (den er nur betreiben kann, da er eh in seiner unbezahlten Freizeit zum Spaß werkelt).
Binärkompatibilität ist bei OS schlichtweg nicht notwendig. Das Prinzip Binaries zu installieren liegt doch noch in der Tradition des CS und sollte einmal grundsätzlich in Frage gestellt werden. Zudem wurden Fortschritte beim GCC nur deshalb möglich, weil die Abwärtskompabilität aufgegeben wurde. Wir profitieren alle davon.
> und sollte einmal grundsätzlich in Frage gestellt werden.
Prinzipiell darf man alles in Frage stellen. Nur sollte man am Ende zu einer sachlich begründeten Antwort kommen. Und der Zustand der geradezu traditionellen Binärinkompatibilität unter Linux ist ein Hemmschuh. Warum sollte ein System darunter leiden, wenn es nicht nur Sourcecodekompatibilität bietet, sondern zusätzlich auch Binärkompatibilität?
Der jetzige Zustand ist der, dass nichtmal die Binaries einer Distribution über verschiedene Versionen hinweg binärkompatibel sind. Das mag für Leute mit viel Zeit und dem Wunsch, Detailwissen über ihr System zu erwerben, akzeptabel sein. Für die große Masse, die einen Computer emotionslos als bloßes Werkzeug betrachten, ist es eine Katastrophe. Unter Systemen wie Windows nehme ich mir ein beliebiges Programm, installiere es per Setup.exe und es funktioniert. Unter W98 genauso wie unter WXP.
Es ist pure Ignoranz, dies als nicht erstebenswert zu deklarieren.
> Zudem wurden Fortschritte beim GCC nur deshalb möglich, weil die
> Abwärtskompabilität aufgegeben wurde.
Dann war der gcc entweder früher so schlecht oder er ist jetzt viiiiieeeeel besser als die Konkurrenz ;-)
> Wir profitieren alle davon.
Du vielleicht. Ein paar Gentoo-Freaks vielleicht. Ein paar OSS-Entwickler vielleicht (denn es macht Arbeit, sein Programm für alle gcc-Versionen kompatibel zu halten). Kommerzielle Entwickler freuen sich darüber nicht. Und die meisten Nutzer auch nicht. Ach nein, die interessiert es nicht. Die benutzen eh Win oder Mac.
---
Bei welchen "Anwenderprogrammen" ohne KernelTreiber(!) hattest Du denn schon Probleme bezüglich der "Binärkompatibilität"? Hier sollte man wohl "absichtliche" Binärinkompatibilität die der Distributer aufgrund einer nicht offiziellen freigabe (zb gcc) raushalten. Gnu.Linux leidet (wenn überhaubt) doch wesentlich mehr unter einer mangelden Umsetzung der LSB als unter einer Binärinkompatibilität.
>Es begrenzt Linux auf eine Nische, denn außerhalb der Welt von Leuten, die bereit sind, für ihre Religion, äh ihr Betriebssystem viele Wochenenden und Nächte zu opfern, ist Binärinkompatibilität nicht akzeptabel.
---
Für Entwickler wäre eine breitere LSB unterstützung imho viel sinniger als eine auf Teufel komm raus (um bei deinen Religions "Argumenten" zu bleiben) erreichte
Binärkompatibilität.
>Leider (oder je nach Standpunkt glücklicherweise) ist es das Wesen einer jeden Religion,...
---
Falsches Forum ?
>Denn unter Systemen wie Solaris und Windows habe ich nicht nur Binär-, sondern auch Quellcodekompatibilität.
---
Und wieso laufen viele Windows9X,NT (X) Programme nicht und einige erst nach basteln unter WindowsXP? Wie sieht es mit Windows 3.11 Programmen aus?
>Unter Linux kann ich mich nicht mal drauf verlassen, dass der Name für ein Device sich nicht von einer Distributionsversion zur nächsten ändert. In einem solchen Falle hilft übrigens auch Neuübersetzen nichts. Da muss der Entwickler schon mehr Aufwand betreiben (den er nur betreiben kann, da er eh in seiner unbezahlten Freizeit zum Spaß werkelt).
---
Wenn er "zum Spaß werkelt" wird er erkennen, dass sich ein "werkeln" lohnen würde und er wird es tun - oder eben nicht.
mfg
Nicht notwendigerweise.
Oft sind Anpassungen an andere Compiler auch nur Ergänzungen im Code, weil der g++ da manchmal sehr nett ist und gewisse Sachen automatisch macht.
Der Solaris C++ Compiler ist zum Beispiel recht unbarmherzig was Doppeldeklaration von Variablen in verschiedenen Sichtbarkeitsbreichen betrifft.
Also wenn man zB einen Parameter x und eine lokale Variable x hat.
Ansich nicht falsch, aber vermutlich nicht gewollt, daher gibt es beim Solaris Compiler ein Warning.