Folge dem Video um zu sehen, wie unsere Website als Web-App auf dem Startbildschirm installiert werden kann.
Anmerkung: Diese Funktion ist in einigen Browsern möglicherweise nicht verfügbar.
Echt? Ich kannte den noch nicht.
Die Generics in Java sind wirklich eine herbe Enttäuschung. Ich sehe hier echt keinen Sinn in den ganzen Einschränkungen die da drin stecken.
Mit dem ganzen .NET Kram habe ich auch noch keine Erfahrung. Vielleicht taugt's ja wirklich was ...
obwohl ich mir das nicht wirklich so recht vorstellen kann.
Echt? Ich kannte den noch nicht.
BTW: .net und C# & friends kenne ich nicht, aber schlechter als Java kann's eigentlich nicht sein. Immerhin sitzen einige der .net-Nasen bei Microsoft-Research mit einigen wichtigen Haskell-Entwicklern quasi auf dem gleichen Flur, da koennte zumindest irgendwann mal so etwas wie ein ordentliches Typsystem auch fuer die "Praxis" bei rauspurzeln (und nicht so ein halbherzige drangeklatschtes Zeugs wie die Generics in Java). Und eine Opensource-Implementierung gibt's mit mono ja auch. Wo also ist das Problem?
Da finde ich es eher spannend wann mal der erste auf die Idee kommt Java auf das .net Framework zu portieren
IKVM.net?
Genial!
Aber Java und .NET ist ja der selbe ****** *duck*
Naja, der Hauptunterschied zwischen beiden ist, dass .NET auf Sprachunabhängigkeit und Java auf Plattformunabhängigkeit getrimmt ist.
Würden aber mehr Programme bzw. Bibliotheken in solchen Managed-Sprachen programmiert wären, gäbe es bei weitem nicht so viele Sicherheitslücken. Denn solche Sachen wie Buffer-Overflows sind dort nicht möglich.
Aber solange Programme/Bibliotheken noch in "nativen" Sprachen wie C oder C++ geschrieben werden, haben wir auch noch mit Bufferoverflows und den dazugehörigen Sicherheitslücken zu kämpfen.
Nicht wirklich. Wenn, dann musst Du die JVM mit .NET verglecihen. Oder Java mti C# (und was sonst noch so rumschwirrt, also Zeugs wie Scala fuer die JVM oder F# fuer .NET).
kili schrieb:Das mit der Plattformunabhaengigkeit ist doch nur graue Theorie, solange es nur ein oder zwei wirklich benutzbare Implementierungen gibt, die auf einer handvoll Plattformen laufen. Vor zehn Jahren, da gab''s noch JDKs fuer VMS/alpha und HPUX/hppa, wird das heute noch weiterentwickelt? Ich glaube nicht.
kili schrieb:Doch, sind sie. Weil das ganze Geraffel, dass fuer die Laufzeitumgebung benoetigt wird, derart komplex ist, dass ihm die Fehler zu den Ohren rauskommen. Ich habe auch in Java von SIGSEGV ueber SIGILL bis hin zu SIGBUS schon alles erlebt. Das waren alles Bugs in der JVM, meistens im JIT (war aber kein JVM von Sun, um deren Ehre mal zu retten).
Geeks, in Beziehungen....die "sex"-szene war ja endgeil!!!
Doch, sind sie. Weil das ganze Geraffel, dass fuer die Laufzeitumgebung benoetigt wird, derart komplex ist, dass ihm die Fehler zu den Ohren rauskommen.
Es gibt durchaus kritische Bugs jenseits von Bufferoverflows. Ich sehe wirklich nicht, wo Sprachen mit impliziter Speicherverwaltung irgendwelche Verbesserungen bzgl. Sicherheit bringen.
Das mit der Plattformunabhaengigkeit ist doch nur graue Theorie, solange es nur ein oder zwei wirklich benutzbare Implementierungen gibt
Doch, sind sie.
Es gibt durchaus kritische Bugs jenseits von Bufferoverflows. Ich sehe wirklich nicht, wo Sprachen mit impliziter Speicherverwaltung irgendwelche Verbesserungen bzgl. Sicherheit bringen.
[citation needed]Nein, sind sie nicht. Mit Java oder C# kriegst du so schnell keine Sicherheitslücke fabriziert.
Der Java-Übersetzer des OpenJDK ist in Java geschrieben (was auch seine unerträgliche Startzeit erklärt). Anders sähe es bei der HotSpot JVM aus. Die ist in C++ geschrieben.Denn der Java-Compiler ist in C++ geschrieben [...]
95% aller Statistiken werden spontan frei erfunden.ca. 95% aller Sicherheitslücken sind Buffer-Overflows, [...]
Es gibt genügend andere Angriffsvektoren, nur sind die schlicht noch nicht so populär, z.B. logische Fehler bei der Implementierung oder gar Spezifikation von Sicherheitsabfragen oder arbeiten mit veralteten Daten (entspricht etwa use-after-free in Sprachen, die explizites Freigeben von Speicher erlauben: eigentlich will man nicht mehr mit einem Datum Arbeiten, aber irgendwer hat immer noch einen Zeiger[1] darauf).die durch manipulierte Daten (z.B. ein PDF, oder ein Video) ausgelöst/genutzt werden. Mit einer Managed-Sprache geht das einfach nicht. Punkt aus. Die VM würde mit IndexOutOfBounds o.ä. einfach das Programm beenden und gut ist. Das würde die Sicherheit ENORM verbessern.
Es gibt genügend andere Angriffsvektoren, nur sind die schlicht noch nicht so populär, z.B. logische Fehler bei der Implementierung oder gar Spezifikation von Sicherheitsabfragen oder arbeiten mit veralteten Daten (entspricht etwa use-after-free in Sprachen, die explizites Freigeben von Speicher erlauben: eigentlich will man nicht mehr mit einem Datum Arbeiten, aber irgendwer hat immer noch einen Zeiger[1] darauf).
Wir verwenden essentielle Cookies, damit diese Website funktioniert, und optionale Cookies, um den Komfort bei der Nutzung zu verbessern.
Siehe weitere Informationen und konfiguriere deine Einstellungen