Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
An dieser Stelle sei mal rotzfrech auf http://www.tinymce.com/ verwiesen. *G*
OK, es ist kein Vergleich zu richtigen Textsatz-Programmen, aber vieles was in Word geht, geht hier auch.
Im Grunde ist die ganze Cloud-Computing Geschichte ja nicht neu. Es ist halt nur eine verbesserte Technik, die man schon aus den 70ern/80ern kennt, als es noch Terminals gab. Hier haben sich die Terminals mittels Telnet mit einem Server verbunden, der die Aufgaben erledigte. Nur im Zuge der Minimalisierung konnte man den Terminal so leistungsstark bauen, sodass kein Server mehr von nöten war und der Desktop-PC entstand daraus. Da nun auch die Server immer kleiner und leistungsstärker wurden, greift man diese Technik wieder auf und wird heute als Cloud-Computing verkauft.
Wenn man es streng nimmt ist Cloud Computing sowieso nur ein Buzzword für Technologien und Umsetzungen die bis zu dem Zeitpunkt schon genau in der Form existiert haben und auch genutzt wurden. Aber mit einem so tollen Modewort "verkauft" es sich eben besser.
Aus Marketingsicht ja, da hast du recht. Vor allem entfernter Datenspeicher ist heute einfach "Cloud".
Aus technischer Sicht, so wie es von MS, Amazon, Google etc. verstanden wird, ist es jedoch neu (on-the-fly Skalierbarkeit für Kunden, flexibles Kostenmodell an Nutzung orientiert, bestmögliche Nutzung von Ressourcen und somit bestmögliche Einsparung von Ressourcen durch maximale Serverauslastung weniger Server statt mehrerer halb ausgelasteten Maschinen, Green-IT etc.pp.)
Durch die inflationäre Benutzung des Wortes ist das leider nicht mehr so eindeutig heute. Der Gedanke hinter der Cloud war sicherlich positiv gemeint, aber durch den Patriot Act und ähnliche Dinge finden die Leute hier auf Cbase alles doof, was mit Cloud zu tun hat.
Ich hab nicht geschrieben, dass ich die "Cloud" doof finde. Nur dass es eine Technik ist, die nicht neu ist, sondern nur verbessert und ausgebaut wurde. Ich selber hatte schon desöfteren mit den AWS zu tun gehabt und fands ne tolle Sache.
Nö, ich find nur alles doof, was mit Cloud-Diensten von US-Anbietern zu tun hat, die ihre Server in den USA stehen haben.
Im Endeffekt ist es dasselbe Problem wie mit Facebook. So wie man statt Facebook durchaus auch Diaspora nutzen kann, kann man viele Cloud-Dienste über Owncloud ersetzen. In beiden Fällen hat man deutlich besseren Datenschutz.
Der Anteil dieser Art von Software wird sicherlich zunehmen. Jedoch ist das Potential doch sehr begrenzt.
Bei vielerlei Software macht es keinen und dann wäre da noch der Sicherheitsaspekt.
Viele Programme brauchen umfangreichen Zugriff auf vielerlei Betriebssystem oder Hardware-Funktionen. Man müsste dann mehr an Zugriffen erlauben und das öffnet die Türen für Schadsoftware.
Ein paar Beispiele: CD-Brennsoftware (Zugriff auf Laufwerke und Festplatte), Musikplayer (durchsuchen der Festplatte), ...
Dann gibt es Software die z.b. komplexere Berechnungen durchführen. Hier sind Web-Applikationen einfach zu langsam.
Wer sagt, dass es keine JS-API für Brenner geben wird? Eine HTML5/JS-Spezifikation für Gamepads oder Webcams (aktuell noch eine unangefochtene Domäne von Flash) ist z.B. schon in der Mache. Vor 5-6 Jahren hättest du wohl auch mit dem Kopf geschüttelt wenn ich gesagt hätte, dass Web-Anwendungen direkt auf deiner GPU rendern können. So, und jetzt geh mal auf Google Maps und schalt MapsGL an...
Wozu die Musik auf der lokalen Festplatte lagern? Musik kann man wunderbar auf eine NAS werfen, die selbige dann wahlweise per DAAP-Freigabe an passende Geräte/Programme (Rhythmbox, Banshee, iTunes, iPod,...) rauspumpt, per regulärem Media-Share an den Windows Media Player oder die PS3 pumpt oder, und HIER kommt der Knaller, per HTML5+JS einfach ein kleines Frontend bietet.
Wirf mal einen Blick auf http://demo.owncloud.org/apps/media/index.php
Was meinst du, wo die Musik, die du da plugin-frei spielen kannst, liegt? Bei dir auf der Platte? Greift sie auf deinen Windows Media Player oder sonstwas zu?
Dann gibt es Software die z.b. komplexere Berechnungen durchführen. Hier sind Web-Applikationen einfach zu langsam.
Wie komplex hättest du es gern? Wie wärs mit modernen Ego-Shootern, gestreamt über OnLive? Was komplexeres als ein grafisch aufwendiges Multiplayer-Game wirst du auf keinem regulären PC zum Laufen bekommen. Oh, halt... So n 3,2GHz Quadcore mit ner 2-300€-Grafikkarte ist KEIN reguläres System, zumindest nicht in der Wirtschaft. Für uns Gamer ist das normal, in Firmen ist sowas Luxus.
Komplexe Berechnungen auf Mainframes auszulagern ist genau DIE Idee, wie man Kosten senkt. In den 70ern und 80ern war das die übliche Herangehensweise. Die Generation "Heim-PC" hat das nur vergessen und freut sich heute über Cloud Computing den Ast.
Komplexe Berechnungen auf Mainframes auszulagern ist genau DIE Idee, wie man Kosten senkt. In den 70ern und 80ern war das die übliche Herangehensweise.
Hervorheben sollte man noch, dass diese auf spezialisierter Hardware liefen, die für das Problem wie geschaffen war, die Mainframes.
Heute wird einfach alles in x86 gemacht oder so mancher freut sich heute wie ein Schneemann wenn eine Software CUDA-Unterstützung hat, spezialisierte Hardware!
Das sind die perfekten Probleme um sie "in der Cloud" zu lösen, da stehen dann eben einige spezialisierte Maschinen die das Problem lösen können. Oder es werden einfach wie bei Cloud Servern und Hadoop 50 virtuelle Server gestartet, die zusammen das Problem lösen sollen und wenn sie fertig sind wieder heruntergefahren, du bekommst davon aber nichts mit, außer das es massiv schneller ist, als auf einem Heim-PC.
Client-Server-Modelle (was "die Cloud" ist) eignen sich einfach hervorragend für viele Dinge, das als unpraktikabel abzustempeln verhöhnt die letzten 50 Jahre.
du bist dir aber schon darüber im klaren, dass die gesammte Textvarbeitung im Browser ohne jegliche Kommunikation mit einem Server laufen kann?
Der Server würde nur einmal die "Software" im Form der vielen JS-Dateien und Grafiken an den Browser schicken, danach kann alles beim Client lokal ohne jegliche Serverinteraktion laufen.
Ok, dann ist zwar irgend wie noch eine Web-Abwendung im weiteren Sinne, aber verteilt läuft dann eigentlich nix mehr. Du hast doch da im Grunde nix weiter beschrieben als einen Download + Installation und dann Ausführung lokal auf der Platte, genau so wie es schon seit Angebinn des Internets läuft.
Es sprach ja auch niemand davon, dass eine Web-Anwendung "verteilt" laufen muss, was immer das auch in Bezug auf Web-Anwendungen heissen soll.
Speichern und Laden kannst du die Daten dann eben direkt auf deiner Festplatte oder du lädst/speicherst eben direkt "in der Cloud".
Wer das ganze noch "Web 2.0igier" machen will, der kann dann für Cloud-Dateien auch implementieren, dass 2 Personen gleichzeitig an einer Datei arbeiten können und so Zeug.
Was moonwalker99 beschrieb war eben nicht mehr als eine Client-Server-Anwendung: Bisher hat die Software einer Stadtverwaltung auf einem Rechner lokal gearbeitet und die Daten wurden dann auf einem zentralen Server in der Stadtverwaltung oder sonstwo gespeichert (DB-Verbindung, RPC, eigenes Protokoll), es musste aber immer auf jedem Rechner die Software geupdated werden. Als Web-Anwendung muss eben keine Software mehr lokal installiert werden sondern es wird diese gleich Remote durch HTTP genutzt.
Ok, dann ist zwar irgend wie noch eine Web-Abwendung im weiteren Sinne, aber verteilt läuft dann eigentlich nix mehr. Du hast doch da im Grunde nix weiter beschrieben als einen Download + Installation und dann Ausführung lokal auf der Platte, genau so wie es schon seit Angebinn des Internets läuft.
Auch eine reine Textverarbeitung auf einem Server ist heute schon möglich und in Verwendung. Lies nochmal die Sache mit den Thin Clients. Das ist nun keine Entwicklung von heute, die ist eher von vorgestern.
Wenn die Frage aber nach Web-PRogrammierung und Web-Diensten steht, dann heißt das: Ich lasse mein Zeug im Browser laufen, idealerweise ohne Plugin. Der Speicherort hängt dann von den genauen Anforderungen ab. Pump die Ergebnisse deiner Arbeit zurück auf das Server-Netz oder lagere sie auf deinem USB-Stick, kommt nur auf die Problemstellung an.
Auch verteiltes Rechnen ist heute schon möglich Natürlich ist es aber nicht sinnvoll, da die JavaScript-Runtimes (selbst V8) noch deutlich der Rechenleistung einer hoch optimierten C Anwendung hinterherhinken, aber als zusätzliche Möglichkeit sicherlich gut geeignet, also um kleine Jobs auf viele Rechner zu verteilen.
Als jemand, der seine Karriere im Bereich der Webentwicklung angesiedelt hat, hier meine 2 cents. Ich beziehe mich dabei nur auf sowas wie Unternehmenssoftware, wie CRM-Systeme, usw. Wenn ein Programm übers Internet laufen muss, führt eh kein Weg am Browser vorbei.
Webanwendungen sind heute eine nette Sache - im wesentlichen aus 2 Gründen:
1. weil man hier auf einem standardisierten - wenn auch sehr chaotischem - Umfeld unterwegs ist, und
2. hauptsächlich deshalb, weil die Clients keine rechenstarken PCs mehr sein müssen - man braucht nur noch Rechenpower für den Client-Code, und das ist UI + Validierung.
Was allerdings imho etwas übersehen wird in den letzten Jahren ist, dass letzteres auch anders geht - ich habe auch relativ komplexe Anwendungen im industriellen Umfeld gesehen, die als Java-Anwendung beispielsweise über ein Netzlaufwerk liefen, und damit auch ohne Installation gestartet werden konnten. Dabei bestand dieser Client, genauso wie eine Webseite, aus einer dünnen Schicht mit UI-Code (und genau darin liegt der Punkt!), wobei ein Dicker Application Server im Hintergrund die eigentliche Arbeit gemacht hat.
Generell würde ich sagen, mit den aktuellen Entwicklungen, gerade was JavaScript, HTML und die "großen" Sprachen C# und Java angeht, sind Webanwendungen einfach "State of the Art"; das Management kann was damit anfangen, und wird sich eher dafür entscheiden. Ich persönlich sehe das kritisch; aus User-Sicht ist eine Webseite vom Ansprech-Verhalten her nur mit erheblichem Aufwand so gut hinzubekommen, dass sie sich wie ein natives Programm anfühlt. Es gibt zahlreiche Frameworks und Bibliotheken, die einen super Job in der Richtung machen, ich frage mich doch relativ oft bei der täglichen Entwicklung, wie man diesen Mehraufwand rechtfertigt, nur um manche Dinge im Browser realisiert zu kriegen (Drag & Drop, Grafiken, Schaubilder, ...).
Edit: Nicht vergessen sollte man, dass sich dieser Mehraufwand nicht nur auf hübsche Oberflächen bezieht, sondern auch darauf, dass man sich mit Sicherheitsthemen beschäftigen muss, die bei einem kleinen FatClient gar keine Rolle spielen (SQL Injection, die ganzen Webserver-Lücken, usw. usf.). Es ist einfach so, dass nicht jeder, der Programme schreibt, auch wirklich gut dabei ist. Und das wird im Browserumfeld zum Problem - vergleiche dazu jede Meldung der letzten Monate, die sich mit gehackten Webauftritten befasst...
Ergänzung ()
ice-breaker schrieb:
Auch verteiltes Rechnen ist heute schon möglich Natürlich ist es aber nicht sinnvoll, da die JavaScript-Runtimes (selbst V8) noch deutlich der Rechenleistung einer hoch optimierten C Anwendung hinterherhinken, aber als zusätzliche Möglichkeit sicherlich gut geeignet, also um kleine Jobs auf viele Rechner zu verteilen.
Naja, dieses "C-Argument" halte ich persönlich in der Anwendungsentwicklung für nicht gültig, da ein C-Programm niemals besser skalieren wird, als ein Programm in einer beliebig "langsamen" anderen Sprache - denn das Skalieren hängt allein vom Algorithmus ab. Ein C-Programm wird nur um einen linearen Faktor schneller sein, und jeder, der ein Informatikstudium durchleben musste, weiß, dass lineare Faktoren uninteressant sind
Anders ausgedrückt: selbst wenn eine C-Implementierung dreimal so schnell läuft wie eine andere, wird das auf Dauer kein gutes Argument sein, wenn beide Implementierungen gleich skalieren, und man damit im Zweifel einfach mehr Maschinen daneben stellen kann. Hardware ist billig, und Anwendungs-Entwicklung in testintensiven, maschinennahen Sprachen teuer. Und genau deshalb bin ich ein großer Fan von "sicheren" Sprachen auf dem Server, da man bei Verteilten Systemen als Implementierer schon so genug Fallstricke hat - da braucht man nicht auch Zeigerarithmetik (Deadlocks lol) und dergleichen.