Die Geschwindigkeit bei Plex ist wirklich ein Problem und macht die Applikation fuer taegliche Arbeit unbrauchbar. Bei meinem Test brauchte Plex ca. 20 Minuten, um nur DOS zu booten. Mit so einer Gescheindigkeit moechte ich aber nicht sehen muessen, wie lange es dauert, bis Win geladen ist.
Bleibt nur zu hoffen, dass Plex in der Phase2 endlich mal _wirklich_ schneller wird.
> Ich hab das (zusammen mit Oracle 8i) > für 20,-- DM in Thailand gekauft und moechte > nun mal nen bisschen gucken und üben.
guter mann/gute frau, du hast da nen SCHEISSDRECK gekauft. warum haste dir hier nicht ne illegale kopie von nem freund/ner freundin brennen lassen? hätte dir den flug nach thailand (ach so, du warst da ohnehin gerade mal eben???) aber zumindest den zwanni gespart.
solche Projekte wie plex86 oder auch WINE sind wichtig für die Integration von Windowsprogramme. Wobei plex86 flexibler ist und vom Prinzip her mehr Kompatibilität bietet und darüberhinaus auch noch andere Betriebssysteme laufen lassen kann. Bei der Geschwindigkeit wird es aber immer etwas hinter WINE zurückstehen, was wiederum eine schöne seamless-Integration realisierbar macht. Sprich beide Projekte sind wichtig für die Akzeptanz von Linux.
Ich muß man wieder meinem Unmut Luft machen: Wir brauchen nicht so sehr ein Programm, um verschiedene Intel-Betriebsysteme und Programme auf einem Intel-Rechner zu starten (so wie VMWare, Wine, etc), sondern eher ein Programm, um einmal geschriebene Programme auf (nahmezu) jedem Rechner und jedem Betriebssystem starten zu können (so wie Java, InternetC++, etc. - jedoch sollte es unter der GPL oder LGPL stehen).
Habe erst vor kurzem von IBM eine schlechte Nachricht erhalten. Ich hatte schon öfters an verschiedenen Stellen gehört gehabt, daß IBM die JavaVirtualMachine (das "Herz" von Java) nachprogrammiert hatte. Doch nun erfuhr ich von IBM, das das nicht stimmt. Sie haben für ihre JVM lediglich Veränderungen an Suns JVM vorgenommen. Daher liegen auch bei IBMs JVM der Großteil der Rechte bei Sun. Sun hat das Monopol auf Java, auch wenn sie durch den JavaCommunityProcess und ähnlichem versuchen einen anderen Eindruck zu erwecken.
Doch Java hat nun einmal den Vorteil plattformunabhängig zu sein. Ich denke, genau soetwas brauchen wir als OpenSource-Projekt: Eine VM die auf der unterschiedlichen Hardware und den unterschiedlichen Betriebssystemen schnell läuft. Kann Mandrake (oder jemand anderes) nicht mals solch ein Projekt starten.
Seit dem ich die schölechte Nachricht von IBM erhielt, ist meine Abneigung gegen Java größer denn je. Hoffentlich gibt es dazu bald eine freie Alternative. *hoff*
>Ich glaube kaffe ist am weitesten fortgeschritten
Scheint so... doch es ist im Moment noch nicht unter der GPL !
"In addition, Transvirtual announced plans to deliver the single Kaffe implementation as Open Source code under the GNU General Public License (GPL) by the fourth quarter of this year."
Ausserdem finde ich es problematisch, denn hinter kaffe steht wiederum eine Firma (im Stil von Sun) -> "Transvirtual Technologies, Inc."
>Noch besser als Java und Python ist Ruby.
Naja... kommt draufan was für Anforderungen man hat.
Die GUI ist Plattformabhängig... und nicht nur das, es wird auch zw. GTK/QT, etc. unterschieden.
Ein grosser Vorteil aus meiner Sicht besteht darin, dass JAVA die GUI-Models AWT & Swing bereits "implementiert" haben !
>Falls "Internet C++" zudem das Lizenzmodell postiv ändern sollte, ist Java Geschichte.
Kenn ich nicht... muss ich mich mal informieren
> Abgesehen davon, ANSI-C/C++ ist auch Plattformunabhängig. Mit einem Cross-OS-GUI-Toolkit (falls man UI braucht) sollte das kein Problem sein?
Ein Cross-OS-GUI-Toolkit ? Etwa QT ? Oder gibt es noch andere ?
zudem "falls man UI braucht": Für professionelle Anwendungen ist eine GUI unerlässlich ! Man kann von Anwendern nicht erwarten, dass sie sich in die tiefen des Universums vorhacken müssen, um ein Programm bedienen zu können !
wxwindows und Python. So wuerde ich vorgehen, fuer Plattformunabhaengige einfache GUI Programme. Fuer speziellere Anforderungen ist Plattformunabhaengigkeit dann eh nicht mehr so wichtig.
Vieles läßt sich gar nicht von heute auf morgen umprogrammieren oder gar portieren. Deshalb sind solche Projekte durchaus sinnvoll. Möglicherweise sind sie in Zukunft nicht mehr notwendig, aber bis dahin braucht man sowas einfach.
Was Java angeht, so sehe ich da nicht ganz so schwarz. Zum einen gibt es freie Implementierungen. Zum anderen ist es ja gar nicht so schlecht, wenn die Koordination in einer Hand liegt. Und wenn Dir irgendwas nicht gefällt, dann hast Du die Möglichkeit Dir den Sourcecode zu holen und anzupassen. Oder am CommunityProcess teilzunehmen. Letzlich so, wie beim Linux-Kernel auch, wo es einen offiziellen Kernel gibt aber auch spezifische Varianten.
Was die Alternativen zu Java angeht, so sind diese zwar interessant und für viele Aufgaben vielleicht sogar besser geeignet (deshalb kann man nicht so von Alternative sprechen, weil anderes Ziel), aber bei weitem noch nicht so unterstützt und verbreitet. Aber wie gesagt, ich würde das nicht so sehr als Konkurrenz sehen.
Plattformunabhängigkeit hat Linux eingebaut. Linux läuft (zumindest prinzipiell) auf jeder existierenden Plattform - sofern man Plattform mit Hardware gleichsetzt. Und Java gibt es auch nicht für alle Plattformen. Die Plattformunabhängigkeit ist daher ein schwaches Argument für Java (Java macht aus anderen Gründen Sinn, z.B. wegen seines Programmierstiels).
Ich kann Plex86 (oder abstrakter eine VM) sehr gut gebrauchen, auch um nur mal ein paar Distis in einer virtuellen Umgebung austesten zu können oder um eine Beta/Alpha-Installationsumgebung zu haben).
Es ist wohl kaum das wichtigste Ziel Anwendungen laufen zu lassen. Dazu würde auch ein Dual-Boot reichen.
Java (oder besser die JavaVM) setzt aber im Unterschied zu Linux auf der Anwendungsebene an. Dadurch wird ein Programm vom Betriebssystem entkoppelt. Und das ist der entscheidene Unterschied. Es macht sich ganz gut, wenn man nicht wegen eines einzelnen Programms ein Betriebssystem installieren muss.
Dual-Boot reicht eben nicht. Zum einen der Aufwand (und damit Komfortverlust), wenn ich wegen einer Applikation neu booten muss und zum anderen wird damit der Datenaustausch erschwert. Mit plex86 lassen sich sogar Cut&Paste-Dinge realisieren. Sicherlich leistet ein eine solche VM gute Dienste für Testzwecke und wird dafür sicherlich auch oft verwendet, aber ich sehe ein ganz großes Potential zum einbinden von Fremdanwendungen in Linux (die sich nicht so ohne weiteres Umstellen lassen oder wo der Hersteller das auch gar nicht vorsieht) und damit steigende Akzeptanz von Linux.
Zuerst einmal Hi und Hallo an alle, die mir geantwortet haben.
@ Anonymous:
Die anderen "JVMs" kenne ich alle, ja. Kaffe ist jedoch nicht einmal Java 1.1 kompatibel. Ausserdem laeuft es im 16-bit Modus und hat so seine "kleinen" inkompatiblitaeten zu Java. Die meisten Java 1.1 Programme laufen auf jeden Falls nicht auf Kaffe. Und seit Transvirtual PocketLinux erstellt hat, gibt es nun auch ein Programm, das auf Kaffe laeuft - jedoch nicht auf Java. Mir waere es hierbei lieber, wenn sich Kaffe ganz von Java trennen und etwas eigenes beginnen wuerde. Desweiteren ist Kaffe primaer fuer Embedded Systems entwickelt worden. Daher ist fuer Kaffe auch kein Swing und aehnliches geplant. Und obwohl es fuer Embedded Systems geschaffen wurde ist es erheblich langsamer als Suns J2SE.
Zu dem was Du zu Python sagst: Phython ist zwar frei und vielleicht auch eine tolle Sprache, jedoch ist es eine Scriptsprache. Daraus folgt auch, dass groessere Firmen niemals Programme wie den JBuilder dafuer erstellen werden. JBuilder ist bekanntlich selber in Java geschreiben. Wuerde man also soetwas fuer Python in Python schreiben, dann waere der Quellcode der IDE offen. Und das wollen kommerzielle Firmen nun einmal nicht. Ein weiterer Punkt ist, dass Python - weil es eine Skriptsprache ist - langsamer ist als Java. Zwar zieht Swing die Geschwindigkeit der JavaAnwendungen erheblich nach unten, doch wenn man AWT-Programme mit grafischen Python-Programmen vergleicht, oder Text-basierte Python-Programme mit Text-basierten Java-Programmen, so sind die Java-Programme schneller. Das liegt dadran, da bei Java die Programme in einen Binaercode kompiliert werden, der dem realen Maschienencode sehr aehnlich ist. Dadurch faellt beim Interpretieren/JustInTimeCompilieren nicht so viel Arbeit an, wie beim Interpretieren/JustInTimeCompilieren von Python-Programmen.
@ lucifer:
Ruby ist auch eine Skriptsprache, deshalb existieren dort die gleichen Nachteile wie bei Python, die ich Anonymous schon erwaehnt hatte.
Und bei ANSI-C/C++ ist der Quellcode plattformunabhaengig. Doch nicht zu jedem Programm hast Du den Quellcode. Und nicht jede Firma, die ein Programm erstellt, wird es auf jedem x-beliebigen Rechner kompilieren.
Ich moechte hier nur noch mal an die Telefonauskunfts-CDROM der Telekom erinnern. Das Programm wurde fuer Wintel, MacOS und Linux/Intel geschrieben. Sollte irgendjemand Linux auf einem Alpha oder einer Sparc am laufen haben, dann kann er damit nicht anfangen. :-( Und wollen wir etwa ewig bei IA32 bleiben? Irgendwann moechte ich die Hardware auch mal durch etwas Intel-inkompatibles austauschen. Linux wird dann drauf laufen. Und was ist mit den anderen Programmen? Selbst plex86 wird dann wohl nicht drauf laufen, da es gerade dadrauf optimiert wird, dass es auf Intel-Rechnern laeuft um Betriebsyteme die auf Intel-Rechner laufen dadrauf auszufuehren.
@ Freezer:
Kaffe steht unter der GPL. Einfach unter www.kaffe.org nachsehen. Ausserdem steht es auch im Quelklcode von Kaffe, dass es unter der GPL steht.
Dass hinter Kaffe eine Firma steht, finde ich jedoch nicht so problematisch. Immerhin steht Kaffe ja unter der GPL. Ausserdem hat Transvirtual auch nicht mehr so viel Einfluss auf die Lizenz von Kaffe, wie Sun es mit Java hat. Sun hat noch immer die alleinigen Rechte an Java und kann bestimmen, wie die Lizenz der Nachfolgerversion aussieht. An Kaffe haben inzwischen jedoch schon soviele nicht-TransVirtualer GPL-Code beigesteuert, dass nun Transvirtual ebensowenig etwas an der Lizenz von Kaffe tun kann, wie Linus Torvals etwas an der Lizenz von Linux veraendern kann.
@ Spark:
Die Nachteile von Pythyon habe ich weiter oben erwaehnt. Und wiso ist "fuer speziellere Anforderungen" die "Plattformunabhaengigkeit dann eh nicht mehr so wichtig" ? Ich denke, dass auch groessere Projekte plattformunabhaengig sein sollten.
Und wenn Du meinen solltest, dass fuer Hardwarenahe Programme die Plattformunabhaengigkeit nicht so wichtig sein, dann gucke Dir mal an, wie es heutzutage unter Java realisiert wird: Wenn man dort auf den Prozessor zugreifen muss, dann werden kleine Module in C/C++ mit einem Teil Assembler geschrieben, die hinterher mittels der JNI-Schnittstelle in das Java-Programm integriert werden. Wie das geht kannst Du hier nachlesen: http:// www.haertfelder.com/ JNIintro.html
@ MichaelB:
1. Es gibt keine "vernuenftigen" Java-Implementierungen. Die meisten Programme laufen doch heute auf Java2 und die freien JVMs haben noch immer Probleme mit Java 1.1. 2. Ich bemaengel nicht, dass die Koordination in der Hand von Sun liegt, sondern ich bemaengel deren Monopolstellung. Provokativ ausgedrueckt koennte ich auch sagen: "Es ist doch garnicht so schlecht, dass Windows in der alleinigen Hand von Microsoft liegt. Ist doch besser als Linux, das allen gehoert". Unegfaehr so hoert sich Dein Kommentar an. 3. Es ist nicht so wie bei Linux, wo man mal eben den Quellcode veraendern kann und es verschiedende Varianten gibt. Wenn Du Veraenderungen vornimmst und diese veroeffentlichen willst, dann musst Du Dir erst eine Genemigung von Sun holen. Quellcode vom Java nehmen und in ein vollkommen anderes Programm integrieren, dass nichts mit Java zu tun hat ist somit nicht erlaubt. Hingegen darfst Du den Java-Quellcode erweitern. Diese Erweiterungen werden hierbei automatisch Eigentum von Sun Microssytems. Das ist auch der Grund weshalb Microsoft bei seiner ersten Java-Version fuer Linux Code vom Blackdown-Java verwendet hatte ohne diese zu erwaehnen. Um diesen rechtlichen Punkt jedoch zu verschleiern hat Sun bewusst nur Teile vom Blackdown-Java verwendet. Deshalb ist auch heute noch das Sun-Java fuer Linux schlechter als das Blackdown-Java.
@ Philipp:
Sicher, Linux laeuft prinzipiell auf jeder Hardware. Jedoch muessen alle Programme die in C/C++ geschrieben sind fuer jede Hardware neu kompiliert werden. Die Nachteile hierbei habe ich weiter oben erwaehnt.
Zum Punkt mit Plex86: Ich kann verstehen, dass Du damit gerne mal ein paar Distris ausprobieren moechtest. Jedoch solltest Du hierbei nicht vergessen, dass es nur auf der "heilen Intel-Welt" geht. Sobald die Hardware-Architektur Intel-inkompatibel ist, laeuft Plex86 nicht mehr dadrauf. Oder im Fall von Bochs laeuft es erheblich langsam.
Beim Kommentar der an MichaelB ging, ist mir ein kleiner Fehler unterlaufen. Statt "Microsoft" muesste an einer Stelle "Sun" stehen. Richtig heisst es:
Das ist auch der Grund weshalb Sun bei seiner ersten Java-Version fuer Linux Code vom Blackdown-Java verwendet hatte ohne diese zu erwaehnen.
Wembler, ich verstehe nicht ganz... wie laesst Du Programm unter Linux im "16bit Modus" laufen? Oder meinst Du, dass man fuer diese JVM beim booten mem=640k angeben musst?
Die VM von Kaffe laeuft im 16-bit Modus. Wiso weiss ich auch nicht. Einfach mal testen. Das erkennst Du dadran wie gross Integer- und Fload-Zahlen sind und ab der wievielten Stelle die Ungenauigkeit beim Rechnen beginnt. Kaffe kann halt nicht mit der Genauigkeit von Java mithalten. Da jedoch Java selber eine Virtuelle Maschine ist, die bei einem Programm auf jeder Plattform das gleiche Ergebnis liefert (wenn z.B. Rundungsfehler auftreten und das Ergebnis falsch ist, dann ist es bei allen Java-Varianten auf jeder Plattform halt das gleiche falsche Ergebnis), folgt dadraus, dass Kaffe hierbei halt einen eigenen Weg geht. Denn dort sieht das Ergebnis halt anders aus.
Teste einfach Kaffe und vergleiche es mit Java, dann wirst Du sehen was ich meine. Zu Testzwechen kannst Du auch die Beispielprogramme von www.javabuch.de nehmen. Dann stellt Du fest, wie viele Java-Programme Kaffe falsch oder garnicht ausfuehrt.
Zum Thema und Java und Platform unabhängig das ist die größte lüge die man der Menschheit je aufgetischt hat! Hab ihr mal größere Javaprojekte gesehen? Wenn es auf Plattformen wie Mac oder so geht wird es schwierig du siehst überall schon Plattform abhängigen Java Code ala C/C++ (ifdef) dort ist es nur über ander Mechanismen realisiert! Also Java hat sein Ziel verfehlt! Zuedm unstützen Browser wie z.B. der MSIE 4.0/5.0 oder 6.0 immer noch nur Java 1.1.8 und damit kannst du Swing und das Collection Framework in Applets auch vergessen.
Die plattformunabhängigkeit von Java verlagert nur das Problem der plattfromabhängigkeit von einer kapselnden Bibliothek in eine Runtime. Ich kann hier keinen großen Unterschied erkennen.
Für das Verteilen von Binaries ist es kein Vorteil, da die Binaries ja schon für eine Plattform kompiliert wurden und damit nicht mehr portabel sind.
Für das Verteilen von Sourcecode halte ich den Vorteil nur sehr gering, da mit einem einfachen ./configure - make - make install ich unter Linux auf _jeder_ Plattform zurecht komme (soweit die plattformabhängigkeit schon gekapselt wurde).
Es ist hier also nur in bestimmten Fällen ein Vorteil: 1. Internet-Applikationen z.B. Homebanking. Da ist es aber nicht weit her (versuch das mal unter anderen OS's als MS). 2. Serverapplikationen: Da sehe ich aber vor allem nur die Eleganz von Java als Vorteil (so viele verschiedene Plattformen gibt es hier nicht). 3. B2B: Hier kann ich mir einen Einsatz gut vorstellen - das nenne ich dann aber Nische.
Für daheim oder auf der Workstation? pöhhh, da sehe ich ein Linux auf jeder möglichen Hardware als wirklich seelig machende Alternative.
Plex86 kann hier eine Alternative darstellen aber es würde das Problem der Plattformabhängigkeit nicht lösen sondern nur kaschieren. Plex86 bzw. Bochs kann nur ein Notanker sein.
Daher: Linux rulez! (von mir aus auch jedes andere OS wo ./configure - make - make install funktioniert).
Ein Programm, dass bereits geschriebene, und compilierte Programme laufen lässt (also ein Emulator) für jedes Betriebssystem auf jeder Plattform, sollte also jedes Betriebssystem und jede Plattform emulieren, denn sonst kann es ja nicht gehen, d.h. alleine im Falle von Windows alleine schon die gesamten Hardware aufrufe, die Benutzeroberfläche, die gesamten Programmschnittstellen ... und dass für alle Betriebssysteme??? abgesehen, dass dieses Programm wohl die gesamte Performance der CPU alleine dafür aufbrauchen würde, um zu überprüfen, welches Programm welche Funktion in welchem Betriebssystem aufruft verbrauchen würde, wird das erste Problem alleine darin bestehen, die gesamten Dokumentationen der gesamten Funktionsaufrüfe aller Betriebssysteme zu bekommen. und 'unserem Emulator' zu sagen dieses Programm läuft auf dem Betriebssystem, ist dann doch wohl etwas witzlos, denn dann kann man auch für jedes Betriebssystem einen eigenen Emulator haben. oder eben VMWare / Plex86 mit dem man dann die Betriebssysteme nebeneinander laufenlassen kann.
Java hat den Vorteil Plattformunabhängig zu sein? schön. aber Du brauchst dafür dann eben ein Programm, dass in Java geschrieben wurde. Dann lasst uns doch alle in Java Programmieren. Mmmh moment mal, wofür brauche ich denn dann die verschiedenen Plattformen??? dann lass uns doch Java OS nehmen... warum können wir dann nicht irgendein anderes Betriebssystem nehmen? z.B. Linux oder Windows oder OS/2??? Aber dann können doch die bereits vorhandenen Programme nicht mehr laufen. hmmm... dann schreiben wir eben einen Emulator, dann läufts wieder... Äääh momentmal, sind wir da nicht gerade??? Klar. auf Plex86 werden nur x86 Betriebssysteme laufen. zumindest erstmal. vielleicht kommen ja dann doch noch irgendwann andere Zeiten. wenn Transmeta mit Ihrem Prozessor andere Prozessoren emulieren kann, warum soll das dann nicht auch mal direkt unter Software gehen können???
Die Reihenfolge der Events die in Swing auftreten ist z.B. plattformabhängig und die Implementierung der Threads ebenfalls, insbesondere bezueglich der Synchronisierung.
Das letztere ist zwar in der Java Language Reference festgelegt aber nicht jeder haelt sich streng daran. Deshalb sind Anwendungen auch sehr JVM abhängig. Und jede dumme Kommerzielle Anwendung bringt nun um auf Nummer sicher zu gehen eine eigene Java Runtime mit. Super meine Festplatte mag das ganz und gar nicht !!!
Aber portabel ist Java schon, der Aufwand ist sehr gering. Nur mit einem einfachen neucompilieren oder gar auslieferung einer JAR Datei ist es leider oft nicht getan, ein oder zwei Klassen muessen meistens schon noch angepasst werden.
Wenn ich das ganze richtig interpretiere, ist mit Dynamic Translation so etwas wie Code-Morphing gemeint. Dazu faellt mir ein Projekt von HP fuer PA-Risc ein, in dem die einen PA-RiscPA-Risc zwischen Compilations-Layer eingesetzt haben, und damit Performancegewinne bis zu 30 % erreichen konnten. Desweiteren kommt mir da noch dieses Programm in den sinn mit dem man auf Alpha-NT maschinen x86 Winblows Programme laufen lassen konnte...
warum macht man niecht einfach einen zwischen schrit beim compilieren wie bei c# von ms. Den könte man die platformunabhänigeit in die zweite kompiladion undterbringen -> man müste auch keinen sourscode ofenlegen
Nur zur Zeit wirst du mit VMWare doch eher produktiver arbeiten können ...
Bleibt nur zu hoffen, dass Plex in der Phase2 endlich mal _wirklich_ schneller wird.
Ich hab das (zusammen mit Oracle 8i)
für 20,-- DM in Thailand gekauft und moechte
nun mal nen bisschen gucken und üben.
con
> für 20,-- DM in Thailand gekauft und moechte
> nun mal nen bisschen gucken und üben.
guter mann/gute frau, du hast da nen SCHEISSDRECK gekauft. warum haste dir hier nicht ne illegale kopie von nem freund/ner freundin brennen lassen? hätte dir den flug nach thailand (ach so, du warst da ohnehin gerade mal eben???) aber zumindest den zwanni gespart.
GET A LIVE!!
solche Projekte wie plex86 oder auch WINE sind wichtig für die Integration von Windowsprogramme. Wobei plex86 flexibler ist und vom Prinzip her mehr Kompatibilität bietet und darüberhinaus auch noch andere Betriebssysteme laufen lassen kann. Bei der Geschwindigkeit wird es aber immer etwas hinter WINE zurückstehen, was wiederum eine schöne seamless-Integration realisierbar macht.
Sprich beide Projekte sind wichtig für die Akzeptanz von Linux.
Gruß
MichaelB
Habe erst vor kurzem von IBM eine schlechte Nachricht erhalten. Ich hatte schon öfters an verschiedenen Stellen gehört gehabt, daß IBM die JavaVirtualMachine (das "Herz" von Java) nachprogrammiert hatte. Doch nun erfuhr ich von IBM, das das nicht stimmt. Sie haben für ihre JVM lediglich Veränderungen an Suns JVM vorgenommen. Daher liegen auch bei IBMs JVM der Großteil der Rechte bei Sun. Sun hat das Monopol auf Java, auch wenn sie durch den JavaCommunityProcess und ähnlichem versuchen einen anderen Eindruck zu erwecken.
Doch Java hat nun einmal den Vorteil plattformunabhängig zu sein. Ich denke, genau soetwas brauchen wir als OpenSource-Projekt: Eine VM die auf der unterschiedlichen Hardware und den unterschiedlichen Betriebssystemen schnell läuft.
Kann Mandrake (oder jemand anderes) nicht mals solch ein Projekt starten.
Seit dem ich die schölechte Nachricht von IBM erhielt, ist meine Abneigung gegen Java größer denn je. Hoffentlich gibt es dazu bald eine freie Alternative. *hoff*
http:// directory.google.com/ Top/Computers/ Programming/
Languages/Java/ Implementations/
Ich glaube kaffe ist am weitesten fortgeschritten.
Besser als Java ist aber eh python. Genauso plattformunabhängig und eine schönere Sprache. Zudem völlig frei.
Abgesehen davon, ANSI-C/C++ ist auch Plattformunabhängig. Mit einem Cross-OS-GUI-Toolkit (falls man UI braucht) sollte das kein Problem sein?
Scheint so... doch es ist im Moment noch nicht unter der GPL !
"In addition, Transvirtual announced plans to deliver the single Kaffe implementation as Open Source code under the GNU General Public License (GPL) by the fourth quarter of this year."
Ausserdem finde ich es problematisch, denn hinter kaffe steht wiederum eine Firma (im Stil von Sun) -> "Transvirtual Technologies, Inc."
>Noch besser als Java und Python ist Ruby.
Naja... kommt draufan was für Anforderungen man hat.
Die GUI ist Plattformabhängig... und nicht nur das, es wird auch zw. GTK/QT, etc. unterschieden.
Ein grosser Vorteil aus meiner Sicht besteht darin, dass JAVA die GUI-Models AWT & Swing bereits "implementiert" haben !
>Falls "Internet C++" zudem das Lizenzmodell postiv ändern sollte, ist Java Geschichte.
Kenn ich nicht... muss ich mich mal informieren
> Abgesehen davon, ANSI-C/C++ ist auch Plattformunabhängig. Mit einem Cross-OS-GUI-Toolkit (falls man UI braucht) sollte das kein Problem sein?
Ein Cross-OS-GUI-Toolkit ? Etwa QT ? Oder gibt es noch andere ?
zudem "falls man UI braucht":
Für professionelle Anwendungen ist eine GUI unerlässlich ! Man kann von Anwendern nicht erwarten, dass sie sich in die tiefen des Universums vorhacken müssen, um ein Programm bedienen zu können !
Vieles läßt sich gar nicht von heute auf morgen umprogrammieren oder gar portieren. Deshalb sind solche Projekte durchaus sinnvoll. Möglicherweise sind sie in Zukunft nicht mehr notwendig, aber bis dahin braucht man sowas einfach.
Was Java angeht, so sehe ich da nicht ganz so schwarz. Zum einen gibt es freie Implementierungen. Zum anderen ist es ja gar nicht so schlecht, wenn die Koordination in einer Hand liegt. Und wenn Dir irgendwas nicht gefällt, dann hast Du die Möglichkeit Dir den Sourcecode zu holen und anzupassen. Oder am CommunityProcess teilzunehmen. Letzlich so, wie beim Linux-Kernel auch, wo es einen offiziellen Kernel gibt aber auch spezifische Varianten.
Was die Alternativen zu Java angeht, so sind diese zwar interessant und für viele Aufgaben vielleicht sogar besser geeignet (deshalb kann man nicht so von Alternative sprechen, weil anderes Ziel), aber bei weitem noch nicht so unterstützt und verbreitet. Aber wie gesagt, ich würde das nicht so sehr als Konkurrenz sehen.
Gruß
MichaelB
Und Java gibt es auch nicht für alle Plattformen.
Die Plattformunabhängigkeit ist daher ein schwaches Argument für Java (Java macht aus anderen Gründen Sinn, z.B. wegen seines Programmierstiels).
Ich kann Plex86 (oder abstrakter eine VM) sehr gut gebrauchen, auch um nur mal ein paar Distis in einer virtuellen Umgebung austesten zu können oder um eine Beta/Alpha-Installationsumgebung zu haben).
Es ist wohl kaum das wichtigste Ziel Anwendungen laufen zu lassen. Dazu würde auch ein Dual-Boot reichen.
Philipp
Java (oder besser die JavaVM) setzt aber im Unterschied zu Linux auf der Anwendungsebene an.
Dadurch wird ein Programm vom Betriebssystem entkoppelt. Und das ist der entscheidene Unterschied. Es macht sich ganz gut, wenn man nicht wegen eines einzelnen Programms ein Betriebssystem installieren muss.
Dual-Boot reicht eben nicht. Zum einen der Aufwand (und damit Komfortverlust), wenn ich wegen einer Applikation neu booten muss und zum anderen wird damit der Datenaustausch erschwert. Mit plex86 lassen sich sogar Cut&Paste-Dinge realisieren.
Sicherlich leistet ein eine solche VM gute Dienste für Testzwecke und wird dafür sicherlich auch oft verwendet, aber ich sehe ein ganz großes Potential zum einbinden von Fremdanwendungen in Linux (die sich nicht so ohne weiteres Umstellen lassen oder wo der Hersteller das auch gar nicht vorsieht) und damit steigende Akzeptanz von Linux.
Gruß
Michael
@ Anonymous:
Die anderen "JVMs" kenne ich alle, ja. Kaffe ist jedoch nicht einmal Java 1.1 kompatibel. Ausserdem laeuft es im 16-bit Modus und hat so seine "kleinen" inkompatiblitaeten zu Java. Die meisten Java 1.1 Programme laufen auf jeden Falls nicht auf Kaffe. Und seit Transvirtual PocketLinux erstellt hat, gibt es nun auch ein Programm, das auf Kaffe laeuft - jedoch nicht auf Java.
Mir waere es hierbei lieber, wenn sich Kaffe ganz von Java trennen und etwas eigenes beginnen wuerde.
Desweiteren ist Kaffe primaer fuer Embedded Systems entwickelt worden. Daher ist fuer Kaffe auch kein Swing und aehnliches geplant. Und obwohl es fuer Embedded Systems geschaffen wurde ist es erheblich langsamer als Suns J2SE.
Zu dem was Du zu Python sagst: Phython ist zwar frei und vielleicht auch eine tolle Sprache, jedoch ist es eine Scriptsprache. Daraus folgt auch, dass groessere Firmen niemals Programme wie den JBuilder dafuer erstellen werden. JBuilder ist bekanntlich selber in Java geschreiben. Wuerde man also soetwas fuer Python in Python schreiben, dann waere der Quellcode der IDE offen. Und das wollen kommerzielle Firmen nun einmal nicht.
Ein weiterer Punkt ist, dass Python - weil es eine Skriptsprache ist - langsamer ist als Java. Zwar zieht Swing die Geschwindigkeit der JavaAnwendungen erheblich nach unten, doch wenn man AWT-Programme mit grafischen Python-Programmen vergleicht, oder Text-basierte Python-Programme mit Text-basierten Java-Programmen, so sind die Java-Programme schneller. Das liegt dadran, da bei Java die Programme in einen Binaercode kompiliert werden, der dem realen Maschienencode sehr aehnlich ist. Dadurch faellt beim Interpretieren/JustInTimeCompilieren nicht so viel Arbeit an, wie beim Interpretieren/JustInTimeCompilieren von Python-Programmen.
@ lucifer:
Ruby ist auch eine Skriptsprache, deshalb existieren dort die gleichen Nachteile wie bei Python, die ich Anonymous schon erwaehnt hatte.
Und bei ANSI-C/C++ ist der Quellcode plattformunabhaengig. Doch nicht zu jedem Programm hast Du den Quellcode. Und nicht jede Firma, die ein Programm erstellt, wird es auf jedem x-beliebigen Rechner kompilieren.
Ich moechte hier nur noch mal an die Telefonauskunfts-CDROM der Telekom erinnern. Das Programm wurde fuer Wintel, MacOS und Linux/Intel geschrieben. Sollte irgendjemand Linux auf einem Alpha oder einer Sparc am laufen haben, dann kann er damit nicht anfangen. :-(
Und wollen wir etwa ewig bei IA32 bleiben? Irgendwann moechte ich die Hardware auch mal durch etwas Intel-inkompatibles austauschen. Linux wird dann drauf laufen. Und was ist mit den anderen Programmen? Selbst plex86 wird dann wohl nicht drauf laufen, da es gerade dadrauf optimiert wird, dass es auf Intel-Rechnern laeuft um Betriebsyteme die auf Intel-Rechner laufen dadrauf auszufuehren.
@ Freezer:
Kaffe steht unter der GPL. Einfach unter www.kaffe.org nachsehen. Ausserdem steht es auch im Quelklcode von Kaffe, dass es unter der GPL steht.
Dass hinter Kaffe eine Firma steht, finde ich jedoch nicht so problematisch. Immerhin steht Kaffe ja unter der GPL. Ausserdem hat Transvirtual auch nicht mehr so viel Einfluss auf die Lizenz von Kaffe, wie Sun es mit Java hat.
Sun hat noch immer die alleinigen Rechte an Java und kann bestimmen, wie die Lizenz der Nachfolgerversion aussieht. An Kaffe haben inzwischen jedoch schon soviele nicht-TransVirtualer GPL-Code beigesteuert, dass nun Transvirtual ebensowenig etwas an der Lizenz von Kaffe tun kann, wie Linus Torvals etwas an der Lizenz von Linux veraendern kann.
@ Spark:
Die Nachteile von Pythyon habe ich weiter oben erwaehnt.
Und wiso ist "fuer speziellere Anforderungen" die "Plattformunabhaengigkeit dann eh nicht mehr so wichtig" ?
Ich denke, dass auch groessere Projekte plattformunabhaengig sein sollten.
Und wenn Du meinen solltest, dass fuer Hardwarenahe Programme die Plattformunabhaengigkeit nicht so wichtig sein, dann gucke Dir mal an, wie es heutzutage unter Java realisiert wird:
Wenn man dort auf den Prozessor zugreifen muss, dann werden kleine Module in C/C++ mit einem Teil Assembler geschrieben, die hinterher mittels der JNI-Schnittstelle in das Java-Programm integriert werden.
Wie das geht kannst Du hier nachlesen:
http:// www.haertfelder.com/ JNIintro.html
@ MichaelB:
1. Es gibt keine "vernuenftigen" Java-Implementierungen. Die meisten Programme laufen doch heute auf Java2 und die freien JVMs haben noch immer Probleme mit Java 1.1.
2. Ich bemaengel nicht, dass die Koordination in der Hand von Sun liegt, sondern ich bemaengel deren Monopolstellung. Provokativ ausgedrueckt koennte ich auch sagen: "Es ist doch garnicht so schlecht, dass Windows in der alleinigen Hand von Microsoft liegt. Ist doch besser als Linux, das allen gehoert". Unegfaehr so hoert sich Dein Kommentar an.
3. Es ist nicht so wie bei Linux, wo man mal eben den Quellcode veraendern kann und es verschiedende Varianten gibt. Wenn Du Veraenderungen vornimmst und diese veroeffentlichen willst, dann musst Du Dir erst eine Genemigung von Sun holen. Quellcode vom Java nehmen und in ein vollkommen anderes Programm integrieren, dass nichts mit Java zu tun hat ist somit nicht erlaubt.
Hingegen darfst Du den Java-Quellcode erweitern. Diese Erweiterungen werden hierbei automatisch Eigentum von Sun Microssytems.
Das ist auch der Grund weshalb Microsoft bei seiner ersten Java-Version fuer Linux Code vom Blackdown-Java verwendet hatte ohne diese zu erwaehnen. Um diesen rechtlichen Punkt jedoch zu verschleiern hat Sun bewusst nur Teile vom Blackdown-Java verwendet. Deshalb ist auch heute noch das Sun-Java fuer Linux schlechter als das Blackdown-Java.
@ Philipp:
Sicher, Linux laeuft prinzipiell auf jeder Hardware. Jedoch muessen alle Programme die in C/C++ geschrieben sind fuer jede Hardware neu kompiliert werden. Die Nachteile hierbei habe ich weiter oben erwaehnt.
Zum Punkt mit Plex86:
Ich kann verstehen, dass Du damit gerne mal ein paar Distris ausprobieren moechtest. Jedoch solltest Du hierbei nicht vergessen, dass es nur auf der "heilen Intel-Welt" geht. Sobald die Hardware-Architektur Intel-inkompatibel ist, laeuft Plex86 nicht mehr dadrauf. Oder im Fall von Bochs laeuft es erheblich langsam.
Richtig heisst es:
Das ist auch der Grund weshalb Sun bei seiner ersten Java-Version fuer Linux Code vom Blackdown-Java verwendet hatte ohne diese zu erwaehnen.
python kann man auch compilen.... kein problem wegen closed source oder geschwindigkeit...
Die VM von Kaffe laeuft im 16-bit Modus. Wiso weiss ich auch nicht. Einfach mal testen.
Das erkennst Du dadran wie gross Integer- und Fload-Zahlen sind und ab der wievielten Stelle die Ungenauigkeit beim Rechnen beginnt.
Kaffe kann halt nicht mit der Genauigkeit von Java mithalten. Da jedoch Java selber eine Virtuelle Maschine ist, die bei einem Programm auf jeder Plattform das gleiche Ergebnis liefert (wenn z.B. Rundungsfehler auftreten und das Ergebnis falsch ist, dann ist es bei allen Java-Varianten auf jeder Plattform halt das gleiche falsche Ergebnis), folgt dadraus, dass Kaffe hierbei halt einen eigenen Weg geht. Denn dort sieht das Ergebnis halt anders aus.
Teste einfach Kaffe und vergleiche es mit Java, dann wirst Du sehen was ich meine. Zu Testzwechen kannst Du auch die Beispielprogramme von www.javabuch.de nehmen. Dann stellt Du fest, wie viele Java-Programme Kaffe falsch oder garnicht ausfuehrt.
Die plattformunabhängigkeit von Java verlagert nur das Problem der plattfromabhängigkeit von einer kapselnden Bibliothek in eine Runtime.
Ich kann hier keinen großen Unterschied erkennen.
Für das Verteilen von Binaries ist es kein Vorteil, da die Binaries ja schon für eine Plattform kompiliert wurden und damit nicht mehr portabel sind.
Für das Verteilen von Sourcecode halte ich den Vorteil nur sehr gering, da mit einem einfachen ./configure - make - make install ich unter Linux auf _jeder_ Plattform zurecht komme (soweit die plattformabhängigkeit schon gekapselt wurde).
Es ist hier also nur in bestimmten Fällen ein Vorteil:
1. Internet-Applikationen z.B. Homebanking. Da ist es aber nicht weit her (versuch das mal unter anderen OS's als MS).
2. Serverapplikationen: Da sehe ich aber vor allem nur die Eleganz von Java als Vorteil (so viele verschiedene Plattformen gibt es hier nicht).
3. B2B: Hier kann ich mir einen Einsatz gut vorstellen - das nenne ich dann aber Nische.
Für daheim oder auf der Workstation? pöhhh,
da sehe ich ein Linux auf jeder möglichen Hardware als wirklich seelig machende Alternative.
Plex86 kann hier eine Alternative darstellen aber es würde das Problem der Plattformabhängigkeit nicht lösen sondern nur kaschieren. Plex86 bzw. Bochs kann nur ein Notanker sein.
Daher: Linux rulez!
(von mir aus auch jedes andere OS wo ./configure - make - make install funktioniert).
Philipp
Java hat den Vorteil Plattformunabhängig zu sein? schön. aber Du brauchst dafür dann eben ein Programm, dass in Java geschrieben wurde. Dann lasst uns doch alle in Java Programmieren. Mmmh moment mal, wofür brauche ich denn dann die verschiedenen Plattformen??? dann lass uns doch Java OS nehmen... warum können wir dann nicht irgendein anderes Betriebssystem nehmen? z.B. Linux oder Windows oder OS/2??? Aber dann können doch die bereits vorhandenen Programme nicht mehr laufen. hmmm... dann schreiben wir eben einen Emulator, dann läufts wieder... Äääh momentmal, sind wir da nicht gerade???
Klar. auf Plex86 werden nur x86 Betriebssysteme laufen. zumindest erstmal. vielleicht kommen ja dann doch noch irgendwann andere Zeiten. wenn Transmeta mit Ihrem Prozessor andere Prozessoren emulieren kann, warum soll das dann nicht auch mal direkt unter Software gehen können???
Implementierung der Threads ebenfalls, insbesondere bezueglich der Synchronisierung.
Das letztere ist zwar in der Java Language Reference festgelegt aber nicht jeder haelt
sich streng daran. Deshalb sind Anwendungen
auch sehr JVM abhängig. Und jede dumme
Kommerzielle Anwendung bringt nun um auf
Nummer sicher zu gehen eine eigene Java
Runtime mit. Super meine Festplatte mag das
ganz und gar nicht !!!
Aber portabel ist Java schon, der Aufwand
ist sehr gering. Nur mit einem einfachen
neucompilieren oder gar auslieferung einer
JAR Datei ist es leider oft nicht getan,
ein oder zwei Klassen muessen meistens schon
noch angepasst werden.
Dazu faellt mir ein Projekt von HP fuer PA-Risc ein, in dem die einen PA-RiscPA-Risc zwischen Compilations-Layer eingesetzt haben, und damit Performancegewinne bis zu 30 % erreichen konnten.
Desweiteren kommt mir da noch dieses Programm in den sinn mit dem man auf Alpha-NT maschinen x86 Winblows Programme laufen lassen konnte...
Willi
Phase 1 von plex86 realisiert lediglich die Einbettung von:
-Win95(A)
-FreeDOS
-Linux 2.0.x
NT4 ist wohl noch Zukunftsmusik!
----------shnip-------
More recent successes, WinNT 4.0 and QNX demo v4
Tuesday 12th of December 2000 @ 06:07 pm GMT
Recently, I booted WinNT 4.0 from a disk image
file installed under bochs some time ago, and
the QNX demo v4 boot diskette.
--------shnip-----------------
nachdem die erste phase abgeschlossen wurde, wurden "nur" Win, FreeDos und Linux getestet. Wenn ich das richtig mitbekommen hab.
con
----------shnip-------
More recent successes, WinNT 4.0 and QNX demo v4
Tuesday 12th of December 2000 @ 06:07 pm GMT
Recently, I booted WinNT 4.0 from a disk image
file installed under bochs some time ago, and
the QNX demo v4 boot diskette.
--------shnip-----------------
nachdem die erste phase abgeschlossen wurde, wurden "nur" Win, FreeDos und Linux getestet. Wenn ich das richtig mitbekommen hab.
con