Cloudsdale.org

[emosewA]

Cloudsdale.org ist jetzt in der Beta!
Jeder kann sich registrieren und es testen. Ich habe das mal gemacht, werde mal ein bisschen schreiben, worum es dort geht:

Man kann URL's posten (Ist selbsterklärend, denke ich)
Man kann anscheinend NUR URL's posten
Man kann andere Usern "Subscriben"
Es gibt Clouds

Das ist auch schon so ziemlich alles was ich dort gefunden habe. So wie ich das sehe, sind die Clouds das Herzstück. Ich denke, die sind ähnlich den Gruppen bei Facebook. Genau weiß ich das allerdings nicht. Da es bereits eine Cloud für schwedische Bronies gab, hab ich mal eine für deutsche erstellt *klick*. Nunja, wers nicht kennt, sollte auf jeden Fall mal reinschauen. Sieht interessant aus.

[Xris]

Für mich sieht Cloudsdale aus, wie Tumblr nur halt für Bronies. Werd mich mal anmelden und es mir genauer ansehen.

Edit: Der Loginscreen sieht zwar 1:1 wie der von Tumblr aus, aber die eigentliche Webseite nicht mehr. Man kann scheinbar wirklich nur URLs posten. Ich sollte mir die Webseite aber definitiv mal genauer ansehen.

[LittleDog]

und was bringt es wenn man nur links Posten kann?

[AlexLovesCookies]

Versteh ich auch nicht so ganz man kann nur Links posten? und Abbonieren irgendwie sinnlos? ^^

[InLoveWithDashy]

Naja es ist noch in der Beta ich schau mich da auch mal um wer weiß zu was es wird.

[Zechert]

Ich wollte bloß alle darüber informieren, dass es eine neue interessante Seite für Bronies gibt
-------------
http://www.cloudsdale.org/


Equestria Daily Link

Cloudsdale Out of Beta!

The social networking app, Cloudsdale, has left beta and is open for everyone to use. Check out the copy paste below.

Cloudsdale has just left beta and is now publicly available for everypony to use. The application is a unique take on the social network, designed specifically for the Brony community. While most sites created with this purpose in mind have been clones of other popular social networks such as Facebook, Twitter and others, Cloudsdale takes a different route and offers a completely different experience, wrapped up in a beautiful package. Cloudsdale uses the very latest web technologies and is built with a combination of the the powerful Ruby on Rails & Node.js frameworks to ensure that it's users get the best experience possible, with new features being added on a regular basis.

We offer features like

• A beautiful, easy to understand design.
• Support for mobile, with native iOS and Android apps coming soon.
• Live chatting with other users.
• Different "Clouds" for discussion of various topics.
• Built with the latest and greatest web technologies.
• And much more.

Spoiler (Öffnen)

Hoffentlich verstehen die meisten Englisch, bin nämlich zu faul das alles zu übersetzen

[Xris]

Zu Cloudsdale.org haben wir schon einen Thread: http://www.bronies.de/showthread.php?tid=1517

[LittleDog]

und neu isses auch nicht ^^

nur das sie nun endlich aus der Beta sind

[Pulse Wave]

Meine Gedanken zu Cloudsdale.org:

• Jippie, der nächste von Grund auf nur für sich selbst geschriebene, proprietäre Closed-Source-Walled-Garden, der zu nix kompatibel ist als sich selbst... Upps, hoppla, gibt Verbindungen zu Facebook und Twitter. Die sind aber auch nicht viel besser. Natürlich sind diese Verbindungen hardcoded, es gibt keine API oder sonst irgendeine Möglichkeit, sich anderweitig zu verbinden. Und wird es nie geben, weil die Macher wohl nie in Erwägung gezogen haben, daß das gehen könnte. Weil wohl keiner von ihnen jemals in seinem Leben etwas mitbekommen hat von Microblogging-Diensten, die nicht Twitter sind (außer vielleicht dem scheintoten, nicht mehr maintainten Rainbowdash Network, aber wer kennt schon Status.Net, das dem zugrundeliegt), oder Social Networks, die nicht Facebook, Google+ oder MySpace sind.
• Und dann sieht die Facebook-Verbindung auch noch so aus, daß man sich mit seiner Facebook-ID auf Cloudsdale einloggt. Weiß der Geier, was da an Daten an Facebook geht.
• Latest and greatest Web technologies. Ruby on Rails. Ja nee, is klar. Damit ist schon Diaspora* auf die Schnauze geflogen. Siehe unten. Spielt hier natürlich nur eine untergeordnete Rolle, denn Cloudsdale.com ist 100% zentral aufgebaut; es ist überhaupt gar nicht vorgesehen, daß User Serverinstanzen zu Hause oder sonstwo installieren, denn es gibt nur 1 Server. Auch dies zum Thema "latest and greatest Web technologies", denn für mich steht "latest and greatest" für "dezentral, jeder kann sich seinen eigenen Server aufsetzen und hat dann die volle Kontrolle über seine Daten".
• Man sieht der Website förmlich an, daß sie komplett aus einem proprietären grafischen Webentwicklungstool stammt, quasi "zusammengeklickt" ist. Wenn da ein signifikanter Anteil des Codes per Hand geschrieben worden wäre, sähe die Seite nicht halb so verspielt aus und würde vermutlich auch schneller laden.
• Die Oberfläche ist tatsächlich fast komplett in JavaScript ausgeführt. Nicht nur macht das zwingend erforderlich, Scripting für diese Seite zu aktivieren, und frißt eine Menge Leistung durch die ach so coolen Animationen, es macht auch die Verwendung auf Mobilgeräten, wo der Browser entweder kein JavaScript unterstützt oder Scripting komplett abgeschaltet ist, um Leistung bzw. Bandbreite zu sparen, schwierig bis unmöglich. Was ist so schwierig daran, so eine Seite in HTML oder PHP zu bauen, so daß man sie sogar dann noch benutzen kann, wenn man Bilder abgeschaltet hat?
• Dafür gibt's bald eine App für iOS und – oh Wunder – Android. Gegen welche Android-Versionen auf was für Devices mit welcher Bildschirmauflösung getestet, oder läuft die mal wieder nur auf den Bestsellern wie Samsung Galaxy XYZ? Wahrscheinlich wird eh erst die App für iOS rauskommen, und irgendwann, wenn überhaupt, holpert eine je nach Gerät mehr oder weniger lauffähige Android-App hinterher.
• Keine HTTPS-Verbindung möglich oder vorgesehen. Bei einem Social Network ein absolutes No-Go.
• Die Info-Seite ist kompletter Quatsch. Absolut null technische Informationen, und die Mannschaft wird vorgestellt in Form eines riesigen, leistungsfressenden transparenten Scrollbildes, das man nicht beeinflussen kann, also stoppen oder zurückscrollen, man kann nur warten, bis derjenige wieder vorbeikommt.
• Sehr merkwürdig: Normalerweise sehe ich im Firefox 13 (Chakra Linux, Bildschirmauflösung 1280×1024, eingeschränkt durch All-in-One Sidebar, ein paar Toolbars und je eine Systemleiste oben und unten) oben links das nicht funktionierende Twitter-Fenster (NoScript bietet mir übrigens nicht die Option, twitter.com freizuschalten), darunter das Anmeldefenster und rechts davon Colgate. Wenn ich die Sidebar aufklappe und somit das Bild stauche, rutscht das Anmeldefenster nach oben rechts, und beidseitig neben der jetzt mittig auf dem Hintergrund stehenden Colgate tauchen zwei OC-Ponys auf. Kann es sein, daß die Seite nie auf Rechnern älter als zwei Jahre getestet wurde?

Beste Zeichen dafür, daß bei Cloudsdale.org Mac-User in Sachen Technik und Design das Sagen haben (wie schon bei Diaspora*):

• Die ach so tolle, animierte JavaScript-Aufmachung. Aussehen vor Usability.
• Ruby on Rails. Die einzigen Webserver, auf denen Ruby on Rails vorinstalliert ist, sind Macs. Und rubybasierte Websites auf einem Nicht-Mac-Server zum Laufen zu bringen, ist ein Krampf. Tausende, die versucht haben, das von vier Mac-Fanbois für Mac-Server entwickelte (und in seiner ersten Version explizit nur auf Mac-Servern lauffähige) Diaspora* auf einem Linux-Server zum Laufen zu bringen, können davon ein Lied singen.
• Vorschau für die Mobilapp natürlich schön auf einem weißen iPad und einem weißen iPhone.
• Vorschau für die Desktopversion in Safari unter OS X.
• Zumindest das Stylesheet der Startseite – dessen kryptischer Dateiname und Ausführung in Form einer einzigen langen Zeile, die kein Mensch so tippen würde, darauf schließen läßt, daß Cloudsdale.org praktisch ausschließlich mit grafischen Tools gebaut und herzlich wenig Code per Hand geschrieben wurde – ist randvoll mit Webkit-Spezialbefehlen. Cloudsdale.org ist technisch gar nicht dafür vorgesehen, in einem anderen Browser als Safari zu laufen.
• Ebenfalls im Stylesheet fällt auf, daß als erste Schrift unter font-family die Helvetica Neue eingetragen ist (Mac-Exklusivschrift), gefolgt von der Helvetica (wahrscheinlich für ältere Versionen von Mac OS, vom Mac-only-Webdesignprogramm da automatisch eingetragen), der Arial (ja, gut, okay, tragen wir auch mal eine Windows-Schrift ein), und ganz am Ende kommt generell sans-serif. Hat zumindest für uns Linux-Nutzer den Vorteil, daß die Free Sans (falls installiert) zum Einsatz kommt, die von einer Helvetica praktisch nicht zu unterscheiden ist.

[emosewA]

Ich denke nicht, dass dort ein Editor zur Verwendung kam. Das wäre bei einer solch komplexen Webseite mehr Arbeit als ohne. Das CSS ist in einer Zeile um Platz zu sparen. Das JS ist ebenfalls minimiert und in einer Datei zusammengefasst. Aus dem selben Grund wie bei dem CSS.

Du meckerst über RoR und schlägst PHP vor? Das ist noch verfrickelter.

Über JS zwang zu meckern ist in der heutigen Zeit einfach schwachsinnig. So ziemlich niemand hat mehr JS deaktiviert. Und wenn es gut durchdacht ist, sollte das mit der Rechenleistung auch kein all zu großes Problem darstellen.

In einigen Punkten (API, Facebook und Twitter Verbindungen) muss ich dir allerdings zustimmen.

[Pulse Wave]

(15.06.2012)emosewA schrieb:  Ich denke nicht, dass dort ein Editor zur Verwendung kam. Das wäre bei einer solch komplexen Webseite mehr Arbeit als ohne. Das CSS ist in einer Zeile um Platz zu sparen. Das JS ist ebenfalls minimiert und in einer Datei zusammengefasst. Aus dem selben Grund wie bei dem CSS.

Ich halte das einfach mal für unwahrscheinlich, daß ein Webdesigner mit Tools auf dem technischen Niveau von vi tatsächlich from scratch eine Website baut, die in erster Linie im Safari unter Mac OS laufen soll. Siehe WebKit-Spezialbefehle und gezielt vor Windows- und generischen Schriften aufgerufene Mac-Schriften. Niemand baut eine Website per Hand from scratch gegen MacOS, wenn von der Zielgruppe nur ein Bruchteil MacOS nutzen wird.

(15.06.2012)emosewA schrieb:  Du meckerst über RoR und schlägst PHP vor? Das ist noch verfrickelter.

Wenn Cloudsdale dezentral wäre, was es nicht ist, wäre es klüger, es gegen LAMP (Linux, Apache, MySQL, PHP) zu bauen, das es an jeder Ecke auf Webservern baut, als es gegen Dependencies zu bauen, die nur ein Mac problemlos erfüllt.

Auf welcher Datenbank läuft das eigentlich? MongoDB?

(15.06.2012)emosewA schrieb:  Über JS zwang zu meckern ist in der heutigen Zeit einfach schwachsinnig. So ziemlich niemand hat mehr JS deaktiviert. Und wenn es gut durchdacht ist, sollte das mit der Rechenleistung auch kein all zu großes Problem darstellen.

Es gibt immer noch genug Leute, die NoScript schon aus Sicherheitsgründen verwenden. Abgesehen davon geht die Barrierefreiheit einer komplett in JS gebauten Oberfläche gegen null. Abgesehen davon kann eben nicht beispielsweise jeder Mobilbrowser auf Smartphones < iPhone 4GS (oder die weder iOS noch Windows Phone noch Android ab 2.3 haben) so etwas einwandfrei und flüssig darstellen. Tja, und dann gibt's im Mobilbereich noch diejenigen, die selbst in Browsern wie Opera Mobile Bilder und Scripts abschalten, um nicht nach wenigen Tagen schon die 300-MB-pro-Monat-Grenze ihres UMTS-Providers zu erreichen und dann mit ISDN-Tempo weitersurfen zu müssen. Ohne Grafiken ist so eine Website unbenutzbar.

[emosewA]

(19.06.2012)Pulse Wave schrieb:  

(15.06.2012)emosewA schrieb:  Ich denke nicht, dass dort ein Editor zur Verwendung kam. Das wäre bei einer solch komplexen Webseite mehr Arbeit als ohne. Das CSS ist in einer Zeile um Platz zu sparen. Das JS ist ebenfalls minimiert und in einer Datei zusammengefasst. Aus dem selben Grund wie bei dem CSS.

Ich halte das einfach mal für unwahrscheinlich, daß ein Webdesigner mit Tools auf dem technischen Niveau von vi tatsächlich from scratch eine Website baut, die in erster Linie im Safari unter Mac OS laufen soll. Siehe WebKit-Spezialbefehle und gezielt vor Windows- und generischen Schriften aufgerufene Mac-Schriften. Niemand baut eine Website per Hand from scratch gegen MacOS, wenn von der Zielgruppe nur ein Bruchteil MacOS nutzen wird.

Was du schreibst ist absoluter Blödsinn. Wäre die Webseite nun primär für Gecko entwickelt, wäre es dann realistischer, dass sie es from-scratch getan hätten? Davon mal ab, nur weil WebKit Spezialbefehle benutzt wurden, heißt es, dass die Webseite in erster Linie unter Mac OS auf Safari laufen soll? Ich werde dich dann mal informieren: WebKit ist die verbreiteste HTML Rendering Engine. Davon mal ab, sind alle Spezialbefehle auch für Gecko, Opera, IE und sogar KHTML vorhanden, also was ist dein Problem? Wenn du mir nicht glaubst, mach sed -r 's/(;|\{|\})/\1\n/g' auf die CSS und gucke es dir selber an

(19.06.2012)Pulse Wave schrieb:  

(15.06.2012)emosewA schrieb:  Du meckerst über RoR und schlägst PHP vor? Das ist noch verfrickelter.

Wenn Cloudsdale dezentral wäre, was es nicht ist, wäre es klüger, es gegen LAMP (Linux, Apache, MySQL, PHP) zu bauen, das es an jeder Ecke auf Webservern baut, als es gegen Dependencies zu bauen, die nur ein Mac problemlos erfüllt.

Auf welcher Datenbank läuft das eigentlich? MongoDB?

Du willst etwas auf einer Plattform entwickeln nur weil sie weit verbreitet ist? Das ist doch Schwachsinn. Davon mal ab, wissen wir nicht auf was Cloudsdale aufsetzt. Und davon mal ab halte ich es für Schwachsinnig ein solches Netzwerk dezentral zu bauen. Wenn man so etwas wie Cloudsdale noch mal für die breite Masse entwickelt kann man darüber reden, aber nicht bei einem Brony Netzwerk.

(19.06.2012)Pulse Wave schrieb:  

(15.06.2012)emosewA schrieb:  Über JS zwang zu meckern ist in der heutigen Zeit einfach schwachsinnig. So ziemlich niemand hat mehr JS deaktiviert. Und wenn es gut durchdacht ist, sollte das mit der Rechenleistung auch kein all zu großes Problem darstellen.

Es gibt immer noch genug Leute, die NoScript schon aus Sicherheitsgründen verwenden. Abgesehen davon geht die Barrierefreiheit einer komplett in JS gebauten Oberfläche gegen null. Abgesehen davon kann eben nicht beispielsweise jeder Mobilbrowser auf Smartphones < iPhone 4GS (oder die weder iOS noch Windows Phone noch Android ab 2.3 haben) so etwas einwandfrei und flüssig darstellen. Tja, und dann gibt's im Mobilbereich noch diejenigen, die selbst in Browsern wie Opera Mobile Bilder und Scripts abschalten, um nicht nach wenigen Tagen schon die 300-MB-pro-Monat-Grenze ihres UMTS-Providers zu erreichen und dann mit ISDN-Tempo weitersurfen zu müssen. Ohne Grafiken ist so eine Website unbenutzbar.

NoScript hat eine Whitelist und ist ein Script ein mal geladen, ist es im Cache. Davon mal ab, benutzt man so eine Webseite eh nicht auf dem Smartphone. Zu kleiner Bildschirm.

[Pulse Wave]

(03.07.2012)emosewA schrieb:  

(19.06.2012)Pulse Wave schrieb:  

(15.06.2012)emosewA schrieb:  Du meckerst über RoR und schlägst PHP vor? Das ist noch verfrickelter.

Wenn Cloudsdale dezentral wäre, was es nicht ist, wäre es klüger, es gegen LAMP (Linux, Apache, MySQL, PHP) zu bauen, das es an jeder Ecke auf Webservern baut, als es gegen Dependencies zu bauen, die nur ein Mac problemlos erfüllt.

Auf welcher Datenbank läuft das eigentlich? MongoDB?

Du willst etwas auf einer Plattform entwickeln nur weil sie weit verbreitet ist? Das ist doch Schwachsinn. Davon mal ab, wissen wir nicht auf was Cloudsdale aufsetzt. Und davon mal ab halte ich es für Schwachsinnig ein solches Netzwerk dezentral zu bauen. Wenn man so etwas wie Cloudsdale noch mal für die breite Masse entwickelt kann man darüber reden, aber nicht bei einem Brony Netzwerk.

Kommt drauf an. Cloudsdale.org ist 100% zentral auf einen Server ausgelegt, da spielt es an sich wirklich keine Rolle. Wäre Cloudsdale.org nun aber ein neu entwickeltes, dezentrales, föderiertes Netzwerk, das mit beliebig vielen vernetzten privaten und öffentlichen Servern arbeiten würde, wäre das kein Schwachsinn.

Konkrete Beispiele für so etwas: Diaspora* und Friendica. Beides freie, dezentrale soziale Netzwerke, die darauf ausgelegt wurden, daß man sich seinen eigenen Server installieren kann, wo auch immer man will.

Was braucht Friendica? LAMP. Linux, Apache, MySQL, PHP. Kann praktisch jeder Heimserver, kann praktisch jeder Webspaceanbieter.

Was braucht Diaspora*? Ruby on Rails. Ich weiß nicht, wie es heute ist, aber eine Zeitlang war das sogar eine Betaversion, die auf einem Linuxserver nur recht aufwendig installiert werden konnte, weil keine servertaugliche Distribution sie in den Repositories hatte. Und in den ersten Monaten nutzte es als Datenbank MongoDB, bevor nach MySQL migriert wurde. Die allerersten Versionen von Diaspora* waren überhaupt nur auf Mac-Servern lauffähig, denn Diaspora* wurde zunächst mal gegen das entwickelt, was die vier Erstentwickler kannten – den Mac.

[emosewA]

Liest du richtig? Ich rede davon, dass es keinen Sinn gemacht hätte Cloudsdale dezentral aufzubauen. Dafür gibt es einfach zu wenig potentielle User, und der Entwicklungsaufwand wäre viel zu hoch.

Außerdem vestehe ich immer noch nicht wie du ständig von Diaspora auf Cloudsdale schließt. Und was du gegen MongoDB hast.

[Pulse Wave]

(06.07.2012)emosewA schrieb:  Liest du richtig? Ich rede davon, dass es keinen Sinn gemacht hätte Cloudsdale dezentral aufzubauen. Dafür gibt es einfach zu wenig potentielle User, und der Entwicklungsaufwand wäre viel zu hoch.

Das zweifle ich auch nicht an, daß es für eine Handvoll Bronies Overkill gewesen wäre, from scratch, also aus dem Nichts heraus ein komplett neues, dezentrales Social Network zu programmieren.

Allerdings:
a) Es gibt bereits fix und fertig einsetzbare Lösungen, die dezentral gewesen wären.
b) Es hätten sich sicherlich mehrere Bronies oder Bronygruppen gefunden, die für andere Bronies Server hosten würden. Genau wie Bronies, die ihre eigenen Server nur für sich betreiben würden. Der Development-Aufwand hätte sich belaufen auf die Entwicklung von einem oder mehreren neuen Themes für Friendica, damit das Ganze nach Brony-Website aussieht. Sprich, nur Kosmetik. Auch ohne diese Kosmetik hätte man ein sofort einsetzbares, featurereiches, aber freies, offenes und dezentrales Social Network gehabt. Out of the box. Für lau. Auf einem dedizierten LAMP-Server hätte eine Instanz genug Kapazität für einige hundert, wenn nicht gar einige tausend User. Mehrere föderierte Server gleich mehr Kapazität.

(06.07.2012)emosewA schrieb:  Außerdem vestehe ich immer noch nicht wie du ständig von Diaspora auf Cloudsdale schließt.

Weil für mich ein gutes Social Network dezentral sein sollte. Und frei. Und kein Walled Garden. Ich sehe keinen Sinn darin, immer wieder neue zentrale, proprietäre Walled-Garden-Netzwerke von Grund auf neu zu entwickeln.

Diaspora* und Cloudsdale haben übrigens gemeinsam, daß sie beide von praktisch reinen Mac-Usern für Apple-Plattformen entwickelt wurden.

Nur haben die jungen, wenig erfahrenen Entwickler von Diaspora* einen Fehler gemacht: Sie haben ein dezentrales Social Network programmiert mit dem Traum im Hinterkopf, daß jeder User seinen eigenen Pod nur für sich selbst bei sich zu Hause oder bei einem Webhoster betreiben können soll. Sie haben dabei aber völlig ausgeblendet, was auf dem durchschnittlichen Webserver an Voraussetzungen gegeben ist. Ruby on Rails und MongoDB sind sicherlich ganz toll, aber der debianbasierte Plugserver, das webservertaugliche NAS und der Payhoster stellen dir nur PHP und MySQL zur Verfügung. Die ersten Testbuilds haben auf ihren Macs für das frühe Stadium sicherlich annehmbar funktioniert, aber diese ersten Testbuilds haben eben nur auf Macs funktioniert, weil sie nicht cross-platform entwickelt wurden.

Wie gesagt, mir ist an sich ziemlich schnuppe, für welche Serverplattformen ein zentrales Walled-Garden-Network entwickelt wird, solange damit nicht bestimmte Clients aufgrund ihres Betriebssystems oder Browsers ausgeschlossen werden. In diesem konkreten Fall, solange die Entwickler für volle Kompatibilität mit denen sorgen, die weder OS X noch iOS noch einen Apple-Browser haben.

Aber für mich ist das Referenznetzwerk dezentral und plattformübergreifend. Und das ist übrigens nicht Diaspora*.

(06.07.2012)emosewA schrieb:  Und was du gegen MongoDB hast.

MongoDB geht für ein Social Network dann in Ordnung, wenn es zentral ist und der Server bei dir zu Hause steht. Oder du einen gemieteten Rootserver hast, auf dem du tun und lassen und installieren kannst, was du willst, und wo du idealerweise sogar auswählen kannst, welches Betriebssystem auf dem Server läuft.

Für dezentrale Social Networks dagegen ist MongoDB Mist. Für dezentrale Social Networks ist alles außer MySQL Mist. Sagen wir, du willst deine eigene Instanz eines dezentralen Social Network betreiben. Ist ja nicht nur vorgesehen, man wird ja sogar dazu ermutigt, das zu tun, denn darauf sollen dezentrale Social Networks letztlich hinauslaufen. Jetzt willst du aber keine lärmende, stromfressende Serverhardware in deinen eigenen vier Wänden laufen haben. Du hast auch kein Geld für einen Rootserver, nicht mal für einen virtuellen Server. Stinknormaler Mietwebspace muß also reichen. Fällt ja keine große Last an bei nur einem User.

Aber: Strato/1&1/Hosteurope/Domainfactory/Hetzner/All-Inkl/Uberspace/... bieten dir nur LAMP. Jedenfalls in der Preisklasse. Statt Ruby on Rails gibt's da nur PHP, und statt MongoDB gibt's da nur MySQL. Jetzt probier mal, die davon zu überzeugen, nur für dich Ruby on Rails und MongoDB zu installieren. Auf einem Server, wo noch hunderte weitere Kunden drauf sind, die alle mit PHP und MySQL happy sind, und wo du fünf Euro pro Monat für deinen Webspace zahlst, soll dein Hoster eigens für dich Ruby on Rails und MongoDB installieren. Am besten noch Versionen, die in keiner Linux-Serverdistribution in den Paketquellen enthalten sind und daher am Paketmanagement vorbei installiert und händisch konfiguriert werden müssen. Die möglichen Reaktionen reichen von gar nichts über einem höflichen Antwortschreiben, daß das nicht geht, bis hin zum Auslachen in den hostereigenen Büros.

[emosewA]

(08.07.2012)Pulse Wave schrieb:  [...]
a) Es gibt bereits fix und fertig einsetzbare Lösungen, die dezentral gewesen wären.
[...]

Das beweist, dass du Cloudsdale noch nicht ein mal ausprobiert hast, denn es ist grundweg anders als vergleichbare Netzwerke.

(08.07.2012)Pulse Wave schrieb:  [...]
b) Es hätten sich sicherlich mehrere Bronies oder Bronygruppen gefunden, die für andere Bronies Server hosten würden. Genau wie Bronies, die ihre eigenen Server nur für sich betreiben würden. Der Development-Aufwand hätte sich belaufen auf die Entwicklung von einem oder mehreren neuen Themes für Friendica, damit das Ganze nach Brony-Website aussieht. Sprich, nur Kosmetik. Auch ohne diese Kosmetik hätte man ein sofort einsetzbares, featurereiches, aber freies, offenes und dezentrales Social Network gehabt. Out of the box. Für lau. Auf einem dedizierten LAMP-Server hätte eine Instanz genug Kapazität für einige hundert, wenn nicht gar einige tausend User. Mehrere föderierte Server gleich mehr Kapazität.
[...]

Siehe Oben. So einfach ist es eben nicht.

(08.07.2012)Pulse Wave schrieb:  [...]
Diaspora* und Cloudsdale haben übrigens gemeinsam, daß sie beide von praktisch reinen Mac-Usern für Apple-Plattformen entwickelt wurden.
[...]

Jetzt behauptest du das schon wieder. Hast du irgendwelche Probleme mit Cloudsdale in nicht WebKit Engines? Nein hast du nicht, sieht genau so aus. Nur wegen ein paar Screenshots kann man da nicht 'drauf schließen. Viele Screenshoten unter OSX, weil es als "hip" gilt. Und selbst wenn, lass sie OSX benutzen wenn sie wollen, das Betriebssystem hat nichts mit der Darstellung von Webseiten zu tun. Und glaube mir, bei denen läuft sicherlich kein Mac Server.

(08.07.2012)Pulse Wave schrieb:  [...]
Für dezentrale Social Networks dagegen ist MongoDB Mist. Für dezentrale Social Networks ist alles außer MySQL Mist.
[...]

Du weißt aber schon, dass MySQL eine relationale und MongoDB eine dokumentenorientierte Datenbank ist? Das ist etwas vollkommen unterschiedliches. Man sollte eine DB auswählen die zu dem Softwarekonstrukt passt, und keines in eine DB reindrücken, nur weil die eben verbreitet ist. Und schon gar nicht GammelSQL.

(08.07.2012)Pulse Wave schrieb:  [...]
Aber: Strato/1&1/Hosteurope/Domainfactory/Hetzner/All-Inkl/Uberspace/... bieten dir nur LAMP. Jedenfalls in der Preisklasse. Statt Ruby on Rails gibt's da nur PHP, und statt MongoDB gibt's da nur MySQL. Jetzt probier mal, die davon zu überzeugen, nur für dich Ruby on Rails und MongoDB zu installieren. Auf einem Server, wo noch hunderte weitere Kunden drauf sind, die alle mit PHP und MySQL happy sind, und wo du fünf Euro pro Monat für deinen Webspace zahlst, soll dein Hoster eigens für dich Ruby on Rails und MongoDB installieren. Am besten noch Versionen, die in keiner Linux-Serverdistribution in den Paketquellen enthalten sind und daher am Paketmanagement vorbei installiert und händisch konfiguriert werden müssen. Die möglichen Reaktionen reichen von gar nichts über einem höflichen Antwortschreiben, daß das nicht geht, bis hin zum Auslachen in den hostereigenen Büros.

Dann haben die halt Pech gehabt. VServer gibt es ab 8 Euro. Wenn einem seine Privatsphäre dann doch so unwichtig ist, der soll es gleich lassen.