Interressant find ich, dass Musik/Bilder/Videos/Artikel nicht nur auf einzelnen Plattformen wie YouTube vorhanden sind, sondern überall zu erreichen sind. Wie wird sowas eig. technisch umgesetzt? Da geht doch eigentlich ziemlich viel Traffic drauf.
Interressant find ich, dass Musik/Bilder/Videos/Artikel nicht nur auf einzelnen Plattformen wie YouTube vorhanden sind, sondern überall zu erreichen sind. Wie wird sowas eig. technisch umgesetzt? Da geht doch eigentlich ziemlich viel Traffic drauf.
Ähm, was ist an dem Text interessant? Für mich hört sich das so an, als wolle der Autor zukünftig Informationen nicht mehr auf Rechnern sondern auf IP-Adressen speichern. Ist ja auch klasse, so kann man ganz viel abspeichern. Außerdem kann man ganz toll kombinieren, weil man im Web 3.0 nicht mehr mit einer ollen statischen Domain-Adresse wie http://foo.bar/?u=42 verlinkt, sondern z.B. mit coolen Adressen wie c42f:7b92:9a89:582b:fe52:41b2:9d84:f8ce. Das hat so verdammt viele Vorteile, dass selbst das Aufzählen derselben schon überflüssig ist. Ich freue mich wirkilich schon auf Web 4.0. Dann bekommt vermutlich jeder Buchstabe einen eigenen Platz, eine eigene IP-Adresse, im Netz. Das ermöglicht eine noch größere Kombinationsmöglichkeit. Der Autor muss nur noch auswählen, welche Buchstaben-IPs er nutzen möchte und der Besucher kann diese Informationen dann optimal auswerten.
freundliche Grüße, Rolus
Ist vor Allem viel einfacher zu merken.Zitat von Rolus
BTW, mein Bullshit-Detektor schlägt beim Begriff "liquid web" höher aus als bei "Web 2.0". Bei Web 2.0 kann man ja noch den Gedankengang verstehen (auch wenn der Schritt von HTML4+JS/DOM zu HTML4+JS/DOM+HttpRequest+XML eher der Schritt von Web 1.12.7 auf Web 1.13.0 ist), aber liquid web? Der Begriff "flüssig" hat hier keine Bedeutung, er soll nur cool klingen. Willkommen im Land des wilden Bullshits.
Wenn der Autor gewollt hätte, daß man ihn ernst nimmt, hätte er nicht einen Begriff erfunden, der dermaßen auf cool getrimmt aussieht, daß man Flüssignetzseiten wahrscheinlich nur mit Browsern öffnen können darf, die selbst runde Kanten, Farbverläufe und Menüs mit durcheinander geworfenen, unterschiedlich großen Menüpunkten haben.
Es gibt etwas, das Begriffe wie "semantic web" haben und "Web 2.0" nicht - Inhalt. Das semantic web zeichnet sich dadurch aus, daß es semantische Auszeichnung hat. Web 2.0 ist nicht mal der große Versionsschritt, als der es daherkommt. Und das Flüssignetz ist nicht flüssig. "Distributed" oder "dynamic" wären für die Idee angemessen gewesen, "liquid" ist völliger Marketingbullshit. Vermutlich um die hippen Web-2.0-Developer anzulocken, die hinter dem nächsten Buzzword her sind, mit dem sie Investoren abzocken können...
BTW, kennt hier jemand Greg the Bunny? Ich möchte nur kurz auf SK 2.0 verweisen...
Geändert von Jesus_666 (10.09.2006 um 23:52 Uhr)
Also wenn die Entwicklung wirklich wie beschrieben wäre, wäre der Begriff "flüßig" doch ziemlich zutreffend. Seiten, oder allgemeiner "Objekte", werden nicht mehr durch ihre Form, sondern bloß durch die Zusammensetzung definiert - also flüßig, statt fest.
Also zutreffender und aussagekräftiger als "Web 2.0" ist das allemal.
ich finde weiterhin das ist alles schwachsinn.
web, web und web, ich brauche weder web 2.3.4.2 noch liquid noch gas web ...
alles nur doofe schlagworte, die in werbung gut aussehen sollen.
--
cats are not characteristically disposed toward voluntary aerobic exercise
Zwar etwas älter, fasst aber alls über Web 2.0 kurz zusammen: http://www.heise.de/tp/r4/artikel/23/23324/1.html
yay, das is n geiler Artikel, der triffts aber ziemlich genau *sich kugelschreiber ins ohr steck*
--
cats are not characteristically disposed toward voluntary aerobic exercise
...und ein alter...
Naja, ich mag "Web 2.0" nicht. Runde Ecken mag ich, weil sie IMO einfach gut aussehen, aber AJAX stört mehr als dass es nützlich ist, wenn es nicht sinnvoll benutzt wird. Und irgendwelche mit JS gestalteten Animationen x_X Da könnte ich immer kotzen, weil das gleich ne CPU Load von 100% verursacht und nichts bringt. Und tollige Vernetzungen mit Technorati und Schießmichtot benutz ich auch nicht *shrug*
Für so etwas gibt es aber schon Fachbegriffe wie "dynamisch" oder "verteilt", die bereits genau das beschreiben. Nur ist "dynamisch" nicht mehr hip, also müssen wir natürlich einen neuen Begriff mit dem gleichen Inhalt erfinden...
BTW, wer außer mir hat das Gefühl, daß es keine gute Idee ist, die Funktionalität der Seite von mehreren verschiedenen Fremddiensten abhängig zu machen?
Ich. Aber das ist ja Vernetzung und Web 2.0 und toll und ueberhaupt (insbesondere ueberhaupt). Das braucht die Welt!
Ich weiss schon, wieso ich den Web 2.0-Hype nicht sonderlich mag. Okay, mit Ajax kann man nette Sachen machen, aber das macht diesen ganzen Social Networking-Kram nicht nuetzlicher. Ein oder zwei der Bestandteile des Web 2.0 sind brauchbar, der Rest ist imo fuer die Tonne. Allem voran der Begriff "Web 2.0".
Deine rhetorischen Fragen waren auch schon mal besser.
BTW, wer außer mir hat das Gefühl, dass es keine gute Idee ist, einem Hai einen Zungenkuss zu geben?
freundliche Grüße, Rolus
Inwiefern macht man seine Seite von anderen Diensten abhängig? Mir fällt spontan keine Situation ein, in der eine Seite wirklich so stark auf eine andere aufbaut, dass sie ohne diese vollkommen ihre Funktionalität verliert.
Das ist aber eine der Konsequenzen, auf die die "liquid web"-Idee zustrebt. Einzelne Teile der Seite sollen nicht zwangsläufig auf einem Rechner liegen, weil sie ohnehin so behandelt werden, als wären sie völlig unabhängig. Nur, weil ein Teil der "Seite" (das Konzept soll ja gleich mehr oder weniger abgeschafft werden) nich erreichbar ist, muß das ein anderer nicht auch sein - ergo wird davon ausgegangen, daß diese Teile physikalisch verteilt sind.
Das in Verbindung mit folgenden Zitat...
...ergibt den Eindruck, daß der Autor es als erstrebenswert ansieht, wenn alle ihren Kram auf verschiedene Dienste hochladen und dann miteinander verknüpfen. Da allerdings diese jetzt verteilt vorliegenden Dinge ohne einander nur bedingt funktionieren bedeutet das, daß man aus einer Fehlerquelle (dem eigenen Host) mehrere (die Hosts der verwendeten Dienste) macht.
Zumal das ganze Konzept nicht ohne den massiven Einsatz von Indexdiensten funktioniert - wenn also einer der wichtigeren Indexdienste offline ist würde das Auswirkungen auf die Erreichbarkeit des Contents haben. Heute kann zwar Google ausfallen, die Informationen sind aber immer noch erreichbar, wenn man sie finden kann.
Naja, ich denke da koennte man alle wichtigen Punkte und Paradigmen von Distributed Systems darauf beziehen. (Tanenbaum, Stefan + Vandeen haben da ja den Klassiker geschrieben. Das muss ich auch endlich fertig lesen. Als ich irgendwann den Namen am Buchdeckel bemerkt habe, ist mir gleich der legendaerste der legendaeren Flamewars eingefallen. ^^)
Wenn ich mir das so anschaue, dann hat das fuer mich insofern einfach keinen Sinn, da ich bei Scripten immer auf die selben Datenbanken zugreife und das obwohl ich vermeide Ports offen zu lassen, die ich nicht offen lassen muss. Und was da dazu einfach noch mehr greift, ist dass ich OO scripte. Spaetestens hier wird es mit dem vererben umstaendlich, da ich mir da erst ueberlegen muss wie ich meinen Server da hingehend konfiguriere. Auf Webebene sehe ich da doch noch zu wenig Sinn ohne einem verteiltem System etwas derartig aufzusplitten. Und, wenn wir dann so weit sind haben wir eh unsere virtuellen Maschinen die alles fuer uns abstrahieren. Spaetestens dann ist es mir egal. ^^
Aber, da ich oben ja schon den legendaeren Flamewar angesprochen habe: Was denkt ihr? Was ist das schoenste OS-Design? Monolythisch? Mikro? Nano? March?
Ich finde ja das HURD-Design sehr schoen, denke aber dass in Punko Speed ein monolythisches System immernoch am besten ist. Das Problem was ich hier nur sehe ist, dass ich irgendwann so viele Driver im Kernel gelinkt haben koennte, dass er in Summe zu gross ist. Wenn man sich nur anschaut, was da alles heutzutage gebraucht und einfach mitgeliefert wird ist es eigentlich sicher eine schoene huebsche Zahl.
...ich fand ja schon die entwicklung von statischen zu mehr oder weniger dynamischen seiten durch php etc ned sonderlich gut, da ich im web, bis auf solche kommunikationsplatformen wie foren (was ja im grunde nichts anderes als zeitversetzter chat ist) gerne auf eine webseite wie eine buchseite zugreife, als fertiges, eigenständiges produkt.
insofern halte ich auch das vernetzen der ganzen dienste zu solchen patchwork seiten nicht sinvoll.
wenn ich nachrichten lesen will, gehe ich auf spiegel.de wenn ich bilder gucken will auf flickr.de oder google.de wenn ich irgendwelche linklisten brauche, suche ich woanders danach, aber ich brauche keine 100.000x die die diese selbigen auf mehr oder weniger sinvolle art und weise in ihre eigene integrieren.
--
cats are not characteristically disposed toward voluntary aerobic exercise
Ich finde viel weniger die Dienste interessant, als die Formate. Von mir aus kann es für jeden Inhalt einen Dienst geben und die eigene Seite setzt sich aus den Angeboten der Dienste zusammen, von mir aus kann man auch alle Inhalte zusammen für sich selbst betreiben. Das was das ganze für mich "flüssig" macht, wären einheitliche Formate für die Inhalte. Wenn Menschen, Benutzerprofile, etc. bei allen Seiten, Foren und Diensten über ein Format laufen würden, alle Nachrichten ebenfalls, und jeder andere Inhalt auch. Wenn man jedes Objekt/jede Information in einer bestimmten, klar-definierten, maschinen- und menschenverständlichen Sprache speichern würde, und eine Seite aus der Verknüpfung dieser Informationen entstünde, das stelle ich mir darunter vor, und das finde ich interessant. Nur wegen eines lächerlichen Wortes das ganze so fertig zu machen, finde ich schade. :/
Naja, es besteht auch weiterhin das Problem, daß der Autor eine Externalisierung der Seitenfunktionalität vorschlägt, die einfach stabilitätstechnisch keine gute Idee ist. Und das, wovon du sprichst ist etwas völlig anderes - du sprichst einfach vom semantic web. Die Idee ist schon etwas älter.
Obwohl, eigentlich sprichst du nur von der Etablierung, Durchsetzung und Einhaltung von Webstandards, was eine gute (wenn auch etwas illusionäre) Idee ist und mit dem Artikel gar nichts zu tun hat.
Ich würde mit einem monolithischen Kernel anfangen, einfach weil die einfacher zu entwickeln sind und weniger Overhead haben. Von da aus würde ich dort modularisieren, wo es Sinn macht (sowohl stabilitäts- als auch performancetechnisch). Beispielsweise macht es wenig Sinn, den Scheduler als Prozeß zu realisieren - wennn er ein Problem hat ist ohnehin das System in Schwierigkeiten. Einen Treiber für beispielsweise eine Grafikkarte hingegen würde als Modul/Server wohl ganz gut funktionieren.
Im Wesentlichen geht es mir darum, daß reine Mikrokernel dazu neigen, nicht rechtzeitig entwickelt zu werden und zu komplex zu sein, während rein monolithische Kernel zu unflexibel und störanfällig sind. Wenn man vom anderen zum einen geht kriegt man aber durchaus brauchbare Ergebnisse.
Der beste Kernel ist einer, der funktioniert. Mikrokernel sind nett, aber alle großen Betriebssysteme setzen auf Hybridkernel. Ich denke, es ist wie bei RISC und CISC: Es ist keine entweder-oder-Entscheidung sondern ein weites Feld mit vielen Abstufungen. Das beste System ist eins, das sich an dem Punkt zwischen den beiden extremen befindet, wo man die meisten Vorteile hat.
Das genau so stehenz u lassen waere fad.^^ Was sind denn deiner Meinung nach die Eigenschaften die man wo uebernehmen sollte?
Berechtigungen
Zitieren