Hallo zusammen, Ihr kennt sicher ActiveX - eine Microsoft-Technologie zum einbetten von executables in Webseiten. Zunaechst die Vorteile: -native Performanz weil Implementierung in beliebiger Sprache moeglich (inklusive C, Assembler) -Speicherverbrauch ebenfalls potentiell sehr niedrig (wegen niedrigem Overhaed von C Datenstrukturen) Jetzt die Nachteile: -Der Nutzer muss dem Anbieter trauen, da ein ActiveX Objekt praktisch die gleichen Rechte wie beliebige andere Andwendungen besitzt. -Maschinenabhaengig
Warum diese Exkursion ? Ich denke, dass man die enormen Effizienzvorteile von ActiveX mit wirksamen Sicherheitsmechanismen "verheiraten" koennte. Zu diesem Zweck "sperrt" man einfach alle executables einer Website in einen Prozess ein, der per LSM (Linux Security Modules) stark eingeschraenkt wird: Zugriff nur auf Dateien, die von executables dieser Website angelegt wurden; Disk-quaotas pro Website; RAM Quotas usw. Zudem wuerde man ein Plugin fuer firefox(o.ae.) schreiben, welches diesen executables erlaubt, auf einen definierten Bereich des Bildschirms output zu schreiben sowie Input entgegen zu nehmen (falls dieser Bildschirmbereich den Fokus hat).
Mit dieser Technologie koennte man alle Sicherheitsmerkmale von Java Applets vereinigen mit der Performance von native-Anwendungen. Zum Beispiel koennte man 3D-Action Spiele direkt in Webseiten einbauen. Jeder der sich mit Java auseinandergesetzt hat, weiss dass die Performanz und der Ressourcenverbrauch diese Technologie praktisch erledigt haben (mit Ausnahme von Datenbank- Anwendungen...)
Was meint Ihr dazu ? Interessant waere auch die Frage, ob es etwas aequivalentes zum LSM auf Windoze gibt !
Gruss
Frank
On Wednesday 23 May 2007 17:30:15 Frank Gerlach wrote:
Ihr kennt sicher ActiveX - eine Microsoft-Technologie zum einbetten von executables in Webseiten.
(Sorry, dass die Akademiker immer abstrahieren, aber da es nicht nur ActiveX gibt, sondern auch Alternativen aus der Unix-Welt, möchte ich das als Beitrag zum Weltfrieden mal eben auch hier tun.)
Also, wir suchen eine Technologie, mit der man native Desktopkomponenten von Webseiten aus aktivieren kann. Mit Java geht das auch, aber Java ist langsam (v.a. beim initialen Laden) und integriert sich nicht gut in den Desktop. Also gibt es nun überall Komponentenarchitekturen, die auch die Einbettung in Webseiten zulassen. Natürlich ist man sich selbst beim W3C bis heute nicht im klaren, mit welchen Tags und Argumenten das geschehen soll, aber mit ein paar Workarounds bekommt man das für ActiveX, Netscape/Xembed/KDE-Plugins etc. schon hin.
Was meint Ihr dazu ?
Es gibt doch unter Linux bis heute keine weit gebräuchliche API, mit der man als Nutzer seine Rechte einschränken kann. Der root kann das über die Capabilities tun. Hier mal als Skizze:
[super-root ..... root-ohne-netz ... root-ohne-alles][normal-user]
Wir brauchen eine API, die es dem Nutzer ermöglicht, chroot() unwiderruflich für einen Prozess und dessen Kinder aufzurufen, sich vom Netz und Speichermedien zu trennen, Quotas per Verzeichnis festlegen usw.
Irgendwie hatte ich das schonmal beschrieben, 2003: http://mindx.josefspillner.de/uni/linux/sandboxing.html
Da ist das Sandbox-LSM mal erwähnt. Meine Seite ist dazu der 2. Treffer bei Google, eine ordentliche Doku mit Userspace-API, Erklärungen zur Sicherheit etc. findet man nicht. Du darfst mich aber gern darüber aufklären. Ich brauche das nämlich für viele andere Anwendungsfälle auch, z.B. dynamisch nachgeladene Spiele, die Leute daddeln gern und möchten sich ungern mit Sicherheitseinstellungen beschäftigen. X-Server, Soundausgabe etc. müssen natürlich weiterhin nutzbar sein.
Josef
Frank Gerlach schrieb:
Ihr kennt sicher ActiveX - eine Microsoft-Technologie zum einbetten von executables in Webseiten.
Das Einbetten in Webseiten ist nur eine von vielen Anwendungen. ActiveX-Module sind letztlich nur dynamische Bibliotheken (also DLLs), die einem bestimmten COM-Interface genügen.
Zunaechst die Vorteile: -native Performanz weil Implementierung in beliebiger Sprache moeglich (inklusive C, Assembler)
Schlägst Du gerade vor, man solle Plug-Ins in Assembler schreiben? *entsicher_ak47*
-Speicherverbrauch ebenfalls potentiell sehr niedrig (wegen niedrigem Overhaed von C Datenstrukturen)
Man kann in jeder Sprache schlechte Programme schreiben.
Jetzt die Nachteile: -Der Nutzer muss dem Anbieter trauen, da ein ActiveX Objekt praktisch die gleichen Rechte wie beliebige andere Andwendungen besitzt.
Nö, besitzen sie nicht.
Warum diese Exkursion ? Ich denke, dass man die enormen Effizienzvorteile von ActiveX mit wirksamen Sicherheitsmechanismen "verheiraten" koennte. Zu diesem Zweck "sperrt" man einfach alle executables einer Website in einen Prozess ein, der per LSM (Linux Security Modules) stark eingeschraenkt wird: Zugriff nur auf Dateien, die von executables dieser Website angelegt wurden; Disk-quaotas pro Website; RAM Quotas usw. Zudem wuerde man ein Plugin fuer firefox(o.ae.) schreiben, welches diesen executables erlaubt, auf einen definierten Bereich des Bildschirms output zu schreiben sowie Input entgegen zu nehmen (falls dieser Bildschirmbereich den Fokus hat).
In der Theorie tut ActiveX das auch. Wenn Du aber dem Plug-In Zugriff auf die Platte gewähren willst, kannst Du es doch gleich ohne Browser laufen lassen.
Mit dieser Technologie koennte man alle Sicherheitsmerkmale von Java Applets vereinigen mit der Performance von native-Anwendungen. Zum Beispiel koennte man 3D-Action Spiele direkt in Webseiten einbauen. Jeder der sich mit Java auseinandergesetzt hat, weiss dass die Performanz und der Ressourcenverbrauch diese Technologie praktisch erledigt haben (mit Ausnahme von Datenbank- Anwendungen...)
Wenn Du Dich wirklich mit Java auseinandergesetzt hättest, dann wüßtest Du, dass es sich keinesfalls erledigt hat, im Gegenteil. Client-Server-Anwendungen werden zum überwiegenden Teil als Webanwendungen (mit Java-Application-Server-Backend) oder als reine Java-Anwendungen entwickelt (Beweis durch Behauptung!). Performance oder Ressourcenprobleme waren auch noch nie ein Grund, warum sich eine Technologie nicht durchgesetzt hat. Außerdem fragen sich die "Top-Entscheider" eher was ein GB Speicher und ein GHz Taktfrequenz kosten im Verhältnis zu Entwicklungs- und Deploymentzeit. Sieh Dir z.B. mal Java-Entwicklungsumgebungen an und wie erfahrene Entwickler damit umgehen. Da hast Du mit C+Editor+make nicht den Hauch einer Chance. Ehrlich. (KDevelop, Anjuta und Co. reißen es auch nicht raus)
Was meint Ihr dazu ?
Es stellt sich die Frage, warum man Platform-abhängige 3D-Spiele in Webseiten einbetten möchte, statt sie gleich direkt auf dem OS laufen zu lassen. Alles was weniger Performance-hungrig ist wird bereit in großem Stil mit Flash (oder wie immer das jetzt heißt) gemacht. Selbst Java sieht an der Stelle keinen Stich.
Was ist denn Dein Ziel dabei? Was möchtest Du in Webseiten einbetten, was vorhandene Technologien nicht schon bieten (von 3D-Spielen mal abgesehen).
Interessant waere auch die Frage, ob es etwas aequivalentes zum LSM auf Windoze gibt !
Das gibts doch was von Ratio^WVista...
Viele Grüße, Eric
On 5/23/07, Eric-Alexander Schaefer eric@gixgax.de wrote:
Zunaechst die Vorteile: -native Performanz weil Implementierung in beliebiger Sprache moeglich (inklusive C, Assembler)
Schlägst Du gerade vor, man solle Plug-Ins in Assembler schreiben? *entsicher_ak47*
Fuer bestimmte Anwendung (zB alle Arten von Signalverarbeitung ist maximaler Durchsatz gefragt. Den kriegt man nur durch Assembler (zB SSE2 und andere SIMD Technologien)).
-Speicherverbrauch ebenfalls potentiell sehr niedrig (wegen niedrigem
Overhaed von C Datenstrukturen)
Man kann in jeder Sprache schlechte Programme schreiben.
Deswegen auch das Wort "potentiell".
Jetzt die Nachteile:
-Der Nutzer muss dem Anbieter trauen, da ein ActiveX Objekt praktisch
die
gleichen Rechte wie beliebige andere Andwendungen besitzt.
Nö, besitzen sie nicht.
Was sind denn die Einschraenkungen von ActiveX Objekten ??
In der Theorie tut ActiveX das auch. Wenn Du aber dem Plug-In Zugriff auf die Platte gewähren willst, kannst Du es doch gleich ohne Browser laufen lassen.
Das was Du Plug-In nennst soll *nur* die von ihm erzeugten Dateinen lesen koennen. Meine Emails geht ein Spiel auf einem russischen Server nichts an.
und der Ressourcenverbrauch diese Technologie praktisch erledigt haben
(mit
Ausnahme von Datenbank- Anwendungen...)
Wenn Du Dich wirklich mit Java auseinandergesetzt hättest, dann wüßtest Du, dass es sich keinesfalls erledigt hat, im Gegenteil. Client-Server-Anwendungen werden zum überwiegenden Teil als Webanwendungen (mit Java-Application-Server-Backend) oder als reine
Das meinte ich mit "Datenbankanwendung". Diese Anwendungen schicken ein paar SQL Statements ab (die dann von einer in C geschriebenen Datenbankengine wie MySQL, PostGres oder Oracle ausgefuehrt werden) und basteln dann HTML zusammen. Das braucht keine CPU Leistung...
Java-Anwendungen entwickelt (Beweis durch Behauptung!). Performance oder
Ressourcenprobleme waren auch noch nie ein Grund, warum sich eine Technologie nicht durchgesetzt hat.
Zeige mir bitte eine Bildverarbeitungsanwendung, die Java geschrieben ist und die das gleiche tut wie zB GIMP. Das geht schlicht nicht, weil Java mindestens um den Faktor 10 zu ineffizient ist (Speicher und Laufzeit). Oder "Doom" in java ???
Außerdem fragen sich die
"Top-Entscheider" eher was ein GB Speicher und ein GHz Taktfrequenz kosten im Verhältnis zu Entwicklungs- und Deploymentzeit. Sieh Dir z.B. mal Java-Entwicklungsumgebungen an und wie erfahrene Entwickler damit umgehen. Da hast Du mit C+Editor+make nicht den Hauch einer Chance. Ehrlich. (KDevelop, Anjuta und Co. reißen es auch nicht raus)
Das ist fuer die obengenannten Datenbankanwendungen richtig.
Was meint Ihr dazu ?
Es stellt sich die Frage, warum man Platform-abhängige 3D-Spiele in Webseiten einbetten möchte, statt sie gleich direkt auf dem OS laufen zu lassen. Alles was weniger Performance-hungrig ist wird bereit in großem Stil mit Flash (oder wie immer das jetzt heißt) gemacht. Selbst Java sieht an der Stelle keinen Stich.
Warum spielen Menschen mit Computern ?
Was ist denn Dein Ziel dabei? Was möchtest Du in Webseiten einbetten,
was vorhandene Technologien nicht schon bieten (von 3D-Spielen mal abgesehen).
3D Games ohne Installation und mit 100% Sicherheit. Bildbearbeitung in einer Website. High-performance Animationen ohne die Krankheit Flash. Spracherkennung, alle Arten digitaler Signalverarbeitung....
Interessant waere auch die Frage, ob es etwas aequivalentes zum LSM auf
Windoze gibt !
Das gibts doch was von Ratio^WVista...
Was ist damit gemeint ?
Gruss
Frank
Kleine Anmerkung noch: Meine Idee koennte durchaus auch Hybridansätze unterstuetzen: zB eine Grafikengine in Assembler und C, die durch eine Skriptsprache wie PHP/Perl/Python/Smalltalk/Java/undsoweiter gesteuert wird. Entscheidend, dass man Performance und Effizienz bekommt, wenn man sie braucht. Das heisst eben nicht, dass man alles in C oder Assembler machen muss.
Schoenen Abend noch
Frank
Frank Gerlach schrieb:
Fuer bestimmte Anwendung (zB alle Arten von Signalverarbeitung ist maximaler Durchsatz gefragt. Den kriegt man nur durch Assembler (zB SSE2 und andere SIMD Technologien)).
Aha, Du willst also Signalverarbeitung in eine Webseite eingebetten?
-Der Nutzer muss dem Anbieter trauen, da ein ActiveX Objekt praktisch die gleichen Rechte wie beliebige andere Andwendungen besitzt.
Nö, besitzen sie nicht.
Was sind denn die Einschraenkungen von ActiveX Objekten ??
Genau die, die die Ausführungsumgebung festlegt
Das was Du Plug-In nennst soll *nur* die von ihm erzeugten Dateinen lesen koennen. Meine Emails geht ein Spiel auf einem russischen Server nichts an.
Deshalb braucht man noch lange keine Webseite.
Client-Server-Anwendungen werden zum überwiegenden Teil als Webanwendungen (mit Java-Application-Server-Backend) oder als reine
Das meinte ich mit "Datenbankanwendung". Diese Anwendungen schicken ein paar SQL Statements ab (die dann von einer in C geschriebenen Datenbankengine wie MySQL, PostGres oder Oracle ausgefuehrt werden) und basteln dann HTML zusammen. Das braucht keine CPU Leistung...
Ich schrieb nicht von irgendwelchen popligen Webseitengeneratoren.
Java-Anwendungen entwickelt (Beweis durch Behauptung!). Performance oder Ressourcenprobleme waren auch noch nie ein Grund, warum sich eine Technologie nicht durchgesetzt hat.
Zeige mir bitte eine Bildverarbeitungsanwendung, die Java geschrieben ist und die das gleiche tut wie zB GIMP. Das geht schlicht nicht, weil Java mindestens um den Faktor 10 zu ineffizient ist (Speicher und Laufzeit). Oder "Doom" in java ???
Du reduzierst die komplette Bandbreite der Softwareentwicklung auf Bildverarbeitung und 3D-Spiele. Und den Faktor 10 hast Du bestimmt selbst gemessen...
Außerdem fragen sich die "Top-Entscheider" eher was ein GB Speicher und ein GHz Taktfrequenz kosten im Verhältnis zu Entwicklungs- und Deploymentzeit. Sieh Dir z.B. mal Java-Entwicklungsumgebungen an und wie erfahrene Entwickler damit umgehen. Da hast Du mit C+Editor+make nicht den Hauch einer Chance. Ehrlich. (KDevelop, Anjuta und Co. reißen es auch nicht raus)
Das ist fuer die obengenannten Datenbankanwendungen richtig.
Nee is klar. Es gibt also nicht nur Bild-/Signalverarbeitung, 3D-Spiele, sondern auch noch "Datenbankanwendungen". Sonst nix.
Es stellt sich die Frage, warum man Platform-abhängige 3D-Spiele in Webseiten einbetten möchte, statt sie gleich direkt auf dem OS laufen zu lassen. Alles was weniger Performance-hungrig ist wird bereit in großem Stil mit Flash (oder wie immer das jetzt heißt) gemacht. Selbst Java sieht an der Stelle keinen Stich.
Warum spielen Menschen mit Computern ?
Wie meinen?
Was ist denn Dein Ziel dabei? Was möchtest Du in Webseiten einbetten, was vorhandene Technologien nicht schon bieten (von 3D-Spielen mal abgesehen).
3D Games ohne Installation und mit 100% Sicherheit.
Wie schon gesagt, dafür braucht man keine Webseiteneinbettung. Abgesehen davon, daß die meisten 3D-Spiele sich rein vom Datenvolumen beim besten Willen nicht dafür eignen ad-hoc heruntergeladen zu werden.
Bildbearbeitung in einer Website. High-performance Animationen ohne die Krankheit Flash. Spracherkennung, alle Arten digitaler Signalverarbeitung....
In einer Webseite? Was hast Du um Himmels Willen vor? Warum sollte jemand Bildbearbeitung oder Signalverarbeitung in einer Webseite machen wollen?
Interessant waere auch die Frage, ob es etwas aequivalentes zum LSM auf Windoze gibt !
Das gibts doch was von Ratio^WVista...
Was ist damit gemeint ?
Ich kenne Vista nicht, meine aber gelesen zu haben, daß es da diverse Methoden gibt, Anwendungen in Jail einzusperren. Und das ist es was Du für "3D Games ohne Installation und mit 100% Sicherheit" brauchst und letztlich mit LSM machen kannst. Ganz ohne Webseite.
Viele Grüße, Eric
p.s. Ich bin keineswegs ein Java-Fanboy, ich kann es nur nicht leiden, wenn Leute über Dinge herziehen, die sie nicht verstanden haben oder nicht einordnen können.
Am Mittwoch, den 23.05.2007, 20:24 +0200 schrieb Frank Gerlach:
Hallo Frank,
Zunaechst die Vorteile: -native Performanz weil Implementierung in beliebiger Sprache
moeglich
Die Performanz von Java ist in den letzten Jahren schon besser geworden. Jühlich hat mal eine Stelle zur Javaentwicklung ausgeschrieben, sonst laufen auf solchen Kisten eigentlich nur in Fortran geschriebene Simulationen. Die Industrie tut im Moment schwer mit RealTime-Java rummachen, nur braucht man dazu eine spezielle VM, mit der StandardVM von Sun tut man sich etwas schwer für sowas. War mal eine Domäne von Ada.
-Speicherverbrauch ebenfalls potentiell sehr niedrig (wegen
niedrigem
Overhaed von C Datenstrukturen)
Naja, dort sehen auch keine 0815-PC, das Schlimme an Java ist für mich der Garbagecollector, das Ding tut einfach wann es will was es will. Es gibt Unmengen an Literatur zur Thema Verbesserungsvorschläge, jetzt hat Sun Java ja freigegeben. Vielleicht wird es mal eine ISO-Standard und jemand nimmt sich des leidigen GC mal an.
Ansonsten ist es nur eine Sprache.
Zeige mir bitte eine Bildverarbeitungsanwendung, die Java geschrieben ist und die das gleiche tut wie zB GIMP. Das geht schlicht nicht, weil Java mindestens um den Faktor 10 zu ineffizient ist (Speicher und Laufzeit). Oder "Doom" in java ???
Du musst sehen dass die Entwicklungsumgebung und der ganze Kram erstmal geladen werden muss... Doom in Java gibt es, wer's brauch... Mit Java3d und Jogl hat man auch Zugriff auf OpenGL, Software für Linux gab es auch schon in Fedora. Oder auf den Developerseiten von Sun.
Warum spielen Menschen mit Computern ?
Langeweile?
Was ist denn Dein Ziel dabei? Was möchtest Du in Webseiten einbetten, was vorhandene Technologien nicht schon bieten (von 3D-Spielen mal abgesehen).
3D Games ohne Installation und mit 100% Sicherheit. Bildbearbeitung in einer Website. High-performance Animationen ohne die Krankheit Flash. Spracherkennung, alle Arten digitaler Signalverarbeitung....
Interessanter wäre z.B. ein kleines Browserplugin für die Simulation von http://www.modlab.de, da könnte sich jeder gelangweilte PC sich beteiligen. Und wenn der Borneo-Dialekt (http://www.cs.berkley.edu/~darcy/Borneo/) mal eingebaut werden sollte, lernt Java auch mal halbwegs richtig rechnen.
OpenMP ist für Fortran schon ein alter Hut, für Java ist etwas in Entwicklung. RedHat hat OpenMP für C/C++/Fortran in den gcc eingebaut, also ist sowas mittlerweile Mainstream.
Was ist damit gemeint ?
Sprachverarbeitung wünsch ich mir schon lange.
Viele Grüße, Jan
Am Donnerstag, den 24.05.2007, 01:09 +0200 schrieb Jan Rakelmann:
Sprachverarbeitung wünsch ich mir schon lange.
Erledigt: http://de.wikipedia.org/wiki/Oralux http://packages.debian.org/cgi-bin/search_packages.pl?keywords=flite&sea...
jetzt muss nur noch Spracheingabe rein und wir können uns das tippen beim programmieren sparen. Das wird lustig wenn alle quatschen: Raute include spitze Klammer auf ... ;-)
On Thursday 24 May 2007 03:32:39 Jan Rakelmann wrote:
jetzt muss nur noch Spracheingabe rein und wir können uns das tippen beim programmieren sparen. Das wird lustig wenn alle quatschen: Raute include spitze Klammer auf ... ;-)
Es gab (gibt?) das Projekt, welches den Linux-Kernel mit Sprachsynthese vorliest. Habe noch eine alte Ogg-Datei davon (irgendwo im Bereich Dateisysteme quasselt der gerade), finde aber auf die Schnelle die Webseite nicht. Da mit #defines nicht gegeizt wurde, ist es für den Einsatz im Englischunterricht nicht zu empfehlen.
Josef
Jan Rakelmann schrieb:
Naja, dort sehen auch keine 0815-PC, das Schlimme an Java ist für mich der Garbagecollector, das Ding tut einfach wann es will was es will. Es gibt Unmengen an Literatur zur Thema Verbesserungsvorschläge, jetzt hat Sun Java ja freigegeben. Vielleicht wird es mal eine ISO-Standard und jemand nimmt sich des leidigen GC mal an.
Was macht der GC schlechter als malloc/free? Dass der irgendwann anfängt seinen Speicher aufzuräumen ist nämlich kein Argument, denn das macht malloc auch. Ich habe dazu auch mal vor einiger Zeit einen Artikel gelesen, in dem das Zeitverhalten verglichen wurde und da schnitt malloc nicht gerade gut bei ab. Für RT-Anwendungen gibt es auch spezielle RT-GCs.
Viele Grüße, Eric
On 5/24/07, Eric-Alexander Schaefer eric@gixgax.de wrote:
Was macht der GC schlechter als malloc/free?
Er hält die Anwendung einfach mal minutenlang an. Man muss die Javaprozesse im Speicherverbrauch künstlich beschränken, damit sich das Problem in Grenzen hält.
Viele Grüße, Torsten
Torsten Werner schrieb:
On 5/24/07, Eric-Alexander Schaefer eric@gixgax.de wrote:
Was macht der GC schlechter als malloc/free?
Er hält die Anwendung einfach mal minutenlang an. Man muss die Javaprozesse im Speicherverbrauch künstlich beschränken, damit sich das Problem in Grenzen hält.
Nun, "minutenlang" ist vielleicht Stand von vor 6-7 Jahren und malloc friert auch schon mal für einen Moment ein. Ich habe vor 1-2 Jahren mal einen Artikel darüber gelesen. Leider finde ich ihn nicht mehr.
Viele Grüße, Eric
On 5/24/07, Eric-Alexander Schaefer eric@gixgax.de wrote:
Nun, "minutenlang" ist vielleicht Stand von vor 6-7 Jahren und malloc friert auch schon mal für einen Moment ein.
Nein, das ist Stand 2006 auf hochgezüchteten 4-CPU-Opteron-Kisten. Und ja: wir haben uns Experten heran geholt, die Ahnung davon haben, aber die Symptome nur mit dreckigen Workarounds ein wenig lindern können.
Viele Grüße, Torsten
Torsten Werner schrieb:
On 5/24/07, Eric-Alexander Schaefer eric@gixgax.de wrote:
Nun, "minutenlang" ist vielleicht Stand von vor 6-7 Jahren und malloc friert auch schon mal für einen Moment ein.
Nein, das ist Stand 2006 auf hochgezüchteten 4-CPU-Opteron-Kisten. Und ja: wir haben uns Experten heran geholt, die Ahnung davon haben, aber die Symptome nur mit dreckigen Workarounds ein wenig lindern können.
Klingt nach EJB oder ähnlichen Ferkeleien... Ich habe im letzten halben Jahr viel mit Eclipse rummachen müssen und selbst wenn der Speicher über Gebühren voll war, hatte ich nie den Fall, daß da was einfriert.
Viele Grüße, Eric
On 5/24/07, Eric-Alexander Schaefer eric@gixgax.de wrote:
Klingt nach EJB oder ähnlichen Ferkeleien...
Ja das CMS mit http://www.auswaertiges-amt.de; wär hätt's gedacht...
Ich habe im letzten halben Jahr viel mit Eclipse rummachen müssen und selbst wenn der Speicher über Gebühren voll war, hatte ich nie den Fall, daß da was einfriert.
Das ist ja quasi embedded Kram. ;-)
Viele Grüße, Torsten
On Thursday 24 May 2007, Eric-Alexander Schaefer wrote:
Jan Rakelmann schrieb:
Naja, dort sehen auch keine 0815-PC, das Schlimme an Java ist für mich der Garbagecollector, das Ding tut einfach wann es will was es will. Es gibt Unmengen an Literatur zur Thema Verbesserungsvorschläge, jetzt hat Sun Java ja freigegeben. Vielleicht wird es mal eine ISO-Standard und jemand nimmt sich des leidigen GC mal an.
Was macht der GC schlechter als malloc/free?
Der Java-GC ist mit Abstand einer der schlechtesten in der Industrie und ist leider auch nach nahezu einem Jahrzehnt Java nicht in Ordnung gebracht worden.
Ein paar Beispiele: *per Default nimmt er sich exakt 128MB Ram egal ob er sie braucht oder nicht (Vergleich Smalltalk: greift etwa so viel wie gebraucht wird) *wenn die 128MB verbraucht sind ist Schluss. Allokationsfehler. Abstürze. (Smalltalk: versucht mehr Speicher zu bekommen) *man kann die 128MB umkonfigurieren (z.B. auf 64 oder 256), aber dynamisch wird es nicht *man kann dem GC so oft wie man will sagen, dass es jetzt ein guter Zeitpunkt zum aufräumen wäre, er macht nix (Smalltalk: GC ist steuerbar, aber ich habe es noch nie gebraucht) *wenn er dann doch mal losläuft dauert es gerne mal ein paar Minuten (Smalltalk: 20s ist das absolute Maximum auch auf einer lahmen Kiste, unter anderem weil der GC ständig mitläuft und einfach zu beseitigende Objekte schneller aufräumt) *der JGC unterscheidet nicht zwischen temporären und dauerhaften Objekten, Folge: es wird sehr schnell sehr eng im Speicher (Smalltalk: Multi-Layer-Speichermodell das Objekte nach Lebenszeit und Referenzen einsortiert und unterschiedlich behandelt) *etc.pp. ad infinitum ad nauseam...
Konrad
Konrad Rosenbaum schrieb:
On Thursday 24 May 2007, Eric-Alexander Schaefer wrote:
Jan Rakelmann schrieb:
Naja, dort sehen auch keine 0815-PC, das Schlimme an Java ist für mich der Garbagecollector, das Ding tut einfach wann es will was es will. Es gibt Unmengen an Literatur zur Thema Verbesserungsvorschläge, jetzt hat Sun Java ja freigegeben. Vielleicht wird es mal eine ISO-Standard und jemand nimmt sich des leidigen GC mal an.
Was macht der GC schlechter als malloc/free?
Der Java-GC ist mit Abstand einer der schlechtesten in der Industrie und ist leider auch nach nahezu einem Jahrzehnt Java nicht in Ordnung gebracht worden.
Ein paar Beispiele:
Das ist kein Problem der Sprache Java, sondern der JVM. Wenn die JVM nix taugt, kann die Sprache nix dafür. Ich bin sicher, daß Du Dir ganz leicht auch für Smalltalk, Python und Co. schlechte Implementierungen vorstellen kannst. Mit den Sprachen hat das nix zu tun.
Viele Grüße, Eric
Das ist kein Problem der Sprache Java, sondern der JVM. Wenn die JVM nix taugt, kann die Sprache nix dafür. Ich bin sicher, daß Du Dir ganz leicht auch für Smalltalk, Python und Co. schlechte Implementierungen vorstellen kannst. Mit den Sprachen hat das nix zu tun.
Wie sieht es denn mit gcj aus ? Wie ist der GC da implementiert ?
Gruss
Frank
Am Donnerstag, den 24.05.2007, 20:48 +0200 schrieb Eric-Alexander Schaefer:
Das ist kein Problem der Sprache Java, sondern der JVM. Wenn die JVM nix taugt, kann die Sprache nix dafür.
Aber den Kram gibt es nur im Doppelpack. Vielleicht bringt die GNU-Implementierung ja was. Mein Stand ist der, dass dort auch native Binaries erzeugt werden können, hat aber unmittelbar mit dem GC nichts zu tun.
C**: Mehrfachvererbung, Java: keine Spur Ada: Realtime, parallele Abläufe, spätestens in Ada95, Java: man würgt sich ran Smalltalk: steuerbarer GC, Java: Wunschdenken Eiffel: alles ist ein Objekt, Java: elementare Datentypen sind es nicht
Speed, für mich wichtig: FORTRAN IEEE-Kram, normiert: F2003, der Nag kannst
Ich bin sicher, daß Du Dir ganz leicht auch für Smalltalk, Python und Co. schlechte Implementierungen vorstellen kannst. Mit den Sprachen hat das nix zu tun.
Ich habe mir jetzt nochmal die gesammte Diskussion durchgelesen. Worauf willst du eigentlich hinaus?
Jan
Jan Rakelmann schrieb:
Das ist kein Problem der Sprache Java, sondern der JVM. Wenn die JVM nix taugt, kann die Sprache nix dafür.
Aber den Kram gibt es nur im Doppelpack. Vielleicht bringt die GNU-Implementierung ja was. Mein Stand ist der, dass dort auch native Binaries erzeugt werden können, hat aber unmittelbar mit dem GC nichts zu tun.
Es gibt genau _eine_ Sprache Java und es gibt zig JVMs.
C**: Mehrfachvererbung, Java: keine Spur
Ich programmiere seit 12 oder 13 Jahren mit OO-Sprachen und ich habe noch nie Mehrfachvererbung _wirklich_ benötigt.
Ada: Realtime, parallele Abläufe, spätestens in Ada95, Java: man würgt sich ran
Ada hat auch ein ganz anderes Zielpublikum.
Smalltalk: steuerbarer GC, Java: Wunschdenken
Auch das ist Sache der JVM. Es steht Dir frei eine bessere zu schreiben.
Eiffel: alles ist ein Objekt, Java: elementare Datentypen sind es nicht
Das ist Quatsch. int, boolean und Co. sind Vereinfachungen von richtigen Klassen.
Speed, für mich wichtig: FORTRAN
Das ist sicher richtig.
IEEE-Kram, normiert: F2003, der Nag kannst
Das interessiert aber sonst nur einen marginalen Anteil der Entwickler.
Ich bin sicher, daß Du Dir ganz leicht auch für Smalltalk, Python und Co. schlechte Implementierungen vorstellen kannst. Mit den Sprachen hat das nix zu tun.
Ich habe mir jetzt nochmal die gesammte Diskussion durchgelesen. Worauf willst du eigentlich hinaus?
Ich liefere Gegenargumente für Leute die undifferenzierte Behauptungen aufstellen...
Viele Grüße, Eric
Noch ein kleiner Einwurf zum Thema java Effizienz: Auch wenn man eine Super JVM und einen superoptimierenden Compiler hat, belibt die Tatsache bestehen, dass man keine Objekte auf dem Stack anlegen kann, dass keine Objektarrays moeglich sind (sondern nur Referenzarrays) sowie das komplizierte Datenstrukturen immer viele Zeigerdereferenzierungen verlangen. Und wenn man in einer Schleife 10^6 mal etwas dereferenziert macht sich das *sehr wohl* bemerkbar. Man kann also schon sagen, dass Java by Design langsam ist - im Gegensatz zu C++. Dieselbe Aussage trifft auch auf Smalltalk zu...
On Fri, May 25, 2007 at 05:39:22PM +0200, Frank Gerlach wrote: Hi Frank,
Auch wenn man eine Super JVM und einen superoptimierenden Compiler hat, belibt die Tatsache bestehen, dass man keine Objekte auf dem Stack anlegen kann, dass keine Objektarrays moeglich sind (sondern nur Referenzarrays) sowie das komplizierte Datenstrukturen immer viele Zeigerdereferenzierungen verlangen. Und wenn man in einer Schleife 10^6 mal etwas dereferenziert macht sich das *sehr wohl* bemerkbar.
Das man in der Sprache keine Arrays anlegen kann heißt noch lange nicht dass das Runtime Environment keine Speicheroptimierungen vornimmt...
Auch wenn du ein Pointer in einer Schleife dereferenzierst ist es höchst wahrscheinlich das entweder der Compiler die Dereferenzierung cached oder der dereferenzierte Pointer im CPU Cache vorgehalten wird und wir in dem Fall ganz andere Performanceprobleme (X-Server, Console-Ausgabe etc.) haben.
Ich verstehe auch diesen Flameware hier nicht ganz. In der realen Welt nimmt man für jede spezielle Aufgabe ein passendes Werkzeug, genau so verwendet man bei der Programmierung halt eine passende Programmiersprache.
In der Bremsanlage meines Autos möchte ich halt ein Assembler/C Programm laufen haben und keine JRE, Business-Software sollte man der Wartung wegen aber lieber mit Java schreiben, da spielt Performance einfach keine Rolle.
Also bitte beendet jetzt diesen sinnlosen Thread!!!
Ciao, Tobias
On 5/25/07, Tobias Koenig tokoe@kde.org wrote:
Also bitte beendet jetzt diesen sinnlosen Thread!!!
Also Tobias, jetzt komm doch nicht einfach mit Sachargumenten! ;-)
Viele Grüße, Torsten
Am Freitag, den 25.05.2007, 14:32 +0200 schrieb Eric-Alexander Schaefer:
Hallo,
Ada: Realtime, parallele Abläufe, spätestens in Ada95, Java: man würgt sich ran
Ada hat auch ein ganz anderes Zielpublikum.
Hätte man aber locker übernehmen können.
Smalltalk: steuerbarer GC, Java: Wunschdenken
Auch das ist Sache der JVM. Es steht Dir frei eine bessere zu schreiben.
Ebenfalls. Da ich aber kein Java machen muss soll es mir egal sein. Das Witziges ist, dass die Leute die Fortran entwerfen darüber nachdenken das Exceptionhandling ähnlich zu Java zu machen. Aber ein GC kommt bestimmt nicht rein ;-)
IEEE-Kram, normiert: F2003, der Nag kannst
Das interessiert aber sonst nur einen marginalen Anteil der Entwickler.
Sollte aber mehr Leute interessieren, zwischen 0,....irgendwas..9 und 1 liegt die Steuerung eines Atomkraftwerkes. Solang aber die Ideen aus Wuppertal von der Chip-Industrie ignoriert werden bleibt es ein kleines Wunder wenn eine darstellbare Zahl getroffen wird.
In der boost ist irgendwo in numerics eine Funktion nearbyint(), erinnert mich an Fortarn NEAREST().
Ich liefere Gegenargumente für Leute die undifferenzierte Behauptungen aufstellen...
Achso...
Jan
On Friday 25 May 2007, Jan Rakelmann wrote:
Am Freitag, den 25.05.2007, 14:32 +0200 schrieb Eric-Alexander Schaefer:
IEEE-Kram, normiert: F2003, der Nag kannst
Das interessiert aber sonst nur einen marginalen Anteil der Entwickler.
Sollte aber mehr Leute interessieren, zwischen 0,....irgendwas..9 und 1 liegt die Steuerung eines Atomkraftwerkes.
Kleine Umfrage: wer von uns steuert alles Atomkraftwerke? ;-)
Oder anders gefragt: wer von uns braucht Fließkommazahlen, die genauer als IEEE 80bit (long double) sind? (Bitte nur melden, wenn long double wirklich das Ergebnis erheblich verfälscht und eine Multi-Precision-Bibliothek zu langsam ist.)
Solang aber die Ideen aus Wuppertal von der Chip-Industrie ignoriert werden bleibt es ein kleines Wunder wenn eine darstellbare Zahl getroffen wird.
Bitte etwas Perspektive: die Wuppertaler tun alles um sich selbst zu marginalisieren - schlechte bis gar keine Dokumentation, keine Artikel in Zeitschriften die von der Industrie gelesen werden(*), kein Marketing, keine nennenswerten Industriekontakte und so weit ich das sehen konnte Mitarbeit bei der IEEE erst seit Ende 2006(**). Der letzte Punkt gibt immerhin Hoffnung, dass sie lernen können.
(*)Ja, die akademische Literaturliste ist beeindruckend. (**)Ergebnisse also in ca. 5 Jahren.
Konrad
Am Samstag, den 26.05.2007, 11:59 +0200 schrieb Konrad Rosenbaum:
Mein lieber Konrad,
On Friday 25 May 2007, Jan Rakelmann wrote:
Am Freitag, den 25.05.2007, 14:32 +0200 schrieb Eric-Alexander Schaefer:
IEEE-Kram, normiert: F2003, der Nag kannst
Das interessiert aber sonst nur einen marginalen Anteil der Entwickler.
Sollte aber mehr Leute interessieren, zwischen 0,....irgendwas..9 und 1 liegt die Steuerung eines Atomkraftwerkes.
Kleine Umfrage: wer von uns steuert alles Atomkraftwerke? ;-)
Ok, hier habe ich etwas dick aufgetragen, wenn es aber schon so schöne Sprachen wie ADA gibt, und wir im Open Source Uiversium leben, wäre eine größere Verbreitung wünschenswert. Ein passsender Kompiler ist jedenfalls da.
Oder anders gefragt: wer von uns braucht Fließkommazahlen, die genauer als IEEE 80bit (long double) sind? (Bitte nur melden, wenn long double wirklich das Ergebnis erheblich verfälscht und eine Multi-Precision-Bibliothek zu langsam ist.)
Zum daddeln nicht! Bei wirklichen Simulationen läuft die Rechnung lange, mitunter größer > 3 Wochen, und die Rundungsfehler die sich aufsummieren sind erschreckend. Um das einzugrenzen braucht man auch passende Sprachen, wie das komplexe F95/2003.
Solang aber die Ideen aus Wuppertal von der Chip-Industrie ignoriert werden bleibt es ein kleines Wunder wenn eine darstellbare Zahl getroffen wird.
Bitte etwas Perspektive: die Wuppertaler tun alles um sich selbst zu marginalisieren - schlechte bis gar keine Dokumentation, keine Artikel in Zeitschriften die von der Industrie gelesen werden(*), kein Marketing, keine nennenswerten Industriekontakte und so weit ich das sehen konnte Mitarbeit bei der IEEE erst seit Ende 2006(**). Der letzte Punkt gibt immerhin Hoffnung, dass sie lernen können.
(*)Ja, die akademische Literaturliste ist beeindruckend. (**)Ergebnisse also in ca. 5 Jahren.
Kulisch ist 20 Jahre lang rumgerannt und selbst Intel juckt es nicht. Solange die Ihre Prozessoren gerade mal mit IEEE unters Volk werfen können sind die Brüder glücklich. Und der Aufwand es Mathematikerfreundlich zu ändern ist minimal.
Ich habe dir doch schon mal geschrieben, dass die Leute sich im Prozessordesign auskennen und ein VLSI-Design in der Schublade liegen haben.
Der Kram muß nur endlich mal in die Hardware. Die C++-Bibliothek C-XSC ist nett, aber wenn die Hardware es könnte wäre besser.
viele Grüße, ich mach jetzt Wochenende ;-)
Jan
Jan Rakelmann schrieb:
Ok, hier habe ich etwas dick aufgetragen, wenn es aber schon so schöne Sprachen wie ADA gibt, und wir im Open Source Uiversium leben, wäre eine größere Verbreitung wünschenswert. Ein passsender Kompiler ist jedenfalls da.
Ada ist toll, Eiffel ist toll. Aber solange Betriebssysteme und Toolkits in Sprachen aus der C-Familie geschrieben werden, kannst Du die Verbreitung von anderen Sprachen fein säuberlich falten und abheften. Lisp ist schon älter als die Steinkohle und ist unbestreibar sehr mächtig, aber kaum ein Programmieranfänger wird mit Lisp beginnen. Bist Du erstmal in der C-Notation drin, ist es sehr schwer etwas anderes zu lernen und der Geist ist träge. Nicht umsonst haben z.B. PHP und Perl anleihen bei C genommen. Es ist für den Umsteiger eben einfacher. Die einzige ernsthafte Anwendung von Lisp sind Emacs-Macros ;-)
Viele Grüße, Eric
Am Samstag, den 26.05.2007, 17:53 +0200 schrieb Eric-Alexander Schaefer:
Eric,
PHP und Perl
PHP kenn ich nicht. Zu Perl bin ich mal gezwungen worden ;-). Kann schnell sehr kryptisch werden.
einzige ernsthafte Anwendung von Lisp sind Emacs-Macros ;-)
Maxima ist in Lisp geschrieben worden.
Jan
Am Samstag, den 26.05.2007, 11:59 +0200 schrieb Konrad Rosenbaum:
Hallo,
Oder anders gefragt: wer von uns braucht Fließkommazahlen, die genauer als IEEE 80bit (long double) sind? (Bitte nur melden, wenn long double wirklich das Ergebnis erheblich verfälscht und eine Multi-Precision-Bibliothek zu langsam ist.)
Die Biotec-Leute, eine Ausgründung der Informatiker der TU-DD machen auch dem neuen Rechner am Treffs-Bau Proteinfaltungen. Da ist es wichtig.
Solang aber die Ideen aus Wuppertal von der Chip-Industrie ignoriert werden bleibt es ein kleines Wunder wenn eine darstellbare Zahl getroffen wird.
Bitte etwas Perspektive: die Wuppertaler tun alles um sich selbst zu marginalisieren - schlechte bis gar keine Dokumentation, keine Artikel in Zeitschriften die von der Industrie gelesen werden(*), kein Marketing, keine nennenswerten Industriekontakte und so weit ich das sehen konnte Mitarbeit bei der IEEE erst seit Ende 2006(**). Der letzte Punkt gibt immerhin Hoffnung, dass sie lernen können.
Es sind nur ein paar Leute, und Lehre müssen Sie auch machen.
Jan
Hallo,
Eric-Alexander Schaefer schrieb:
Jan Rakelmann schrieb:
Eiffel: alles ist ein Objekt, Java: elementare Datentypen sind es nicht
Das ist Quatsch. int, boolean und Co. sind Vereinfachungen von richtigen Klassen.
Ab Java 5 gibt es zumindest auch Integer, Boolean usw. als richtige Klassen.
Grüße, Matthias
lug-dd@mailman.schlittermann.de
-
Eric-Alexander Schaefer -
Frank Gerlach -
Jan Rakelmann -
Josef Spillner -
Konrad Rosenbaum -
Matthias Petermann -
Tobias Koenig -
Torsten Werner