Friendica mit Durststrecke

Vorweg: es gefällt mir gar nicht! Anscheinend ist die Weiterentwicklung von Friendica etwas eingeschlafen. Hintergründe dazu kenne ich leider keine, noch kann ich irgendetwas zu den Gründen aus den diversen Supportgruppen herauslesen.

Friendica machte sich einst auf, ein soziales Netzwerk für jedermann zu werden und sollte irgendwann eine freie und echte Alternative zu den datenhungrigen kommerziellen Anbietern werden. Besonderer Augenmerk wurde auf die Privatsphäre gelegt und der Grundsatz umgesetzt, dass die Daten dem Erzeuger gehören und er selbst über dessen Verbreitung entscheidet. Dabei ist Friendica ein Meister der Interconnection und kann sich mit vielen anderen sozialen Netzwerken verbinden und Beiträge von dort übernehmen, ja zu einigen Netzwerken sogar exportieren.

Leider scheint es aber auch hier wie in so vielen großen, bisher nur von ambitionierten Enthusiasten erstellten Projekten zu sein: irgendwann ist der eigene Antrieb weg und neu Beitragende sind rar. Selbst Fachleute für Teilaufgaben lassen sich anscheinend nicht mehr finden, denn sonst wäre es unerklärlich, dass Friendica seit Jahren mit einem lahmenden Datenbankmodell daherkommt, es immer noch nicht über eine genormte Schnittstelle für das Installieren und vor allem dem restlosen Deinstallieren von Plugins verfügt und sogar nach vielen Jahren der Entwicklung heute immer noch nicht korrekt mit UTF-8 umgehen kann.

Der Sourcecode des Projekts wird auf GitHub gehostet. Die Commitfrequenz spricht hier eine klare Sprache. Fast schlagartig setzte die Entwicklung gegen Ende 2015 aus.

Friendica Commits

Ich selbst betreibe seit mehreren Jahren einen eigenen Friendica-Server (Update: nicht mehr). Auf diesem bin zwar nur ich selbst zu Hause, konnte aber einige Kontakte, die ich aus anderen Netzwerken kannte auch bei Friendica wiederfinden. Ich würde es vermissen, diesen Vorreiter für selbstgehostet soziale Netzwerke wegen Veralterung, Inkompatibilität oder gar wegen Sicherheitslücken nicht mehr verwenden zu können.

Bewerte diesen Beitrag

13 Gedanken zu „Friendica mit Durststrecke

  1. vinz

    Ich würde da keinen Abgesang anstimmen. Auch GNU Social hat solche "Hänger" in der Entwicklung, bedingt durch die Tatsache dass alle Beteiligten das nur als Hobby machen.

  2. Tobias

    Vorallem würde ich sagen, liegt es daran, dass github für seine Graphen den MASTER Branch auswertet, nicht aber den DEVELOP Branch, in dem die Entwicklungsarbeiten stattfinden.

    OpenHUB hat den Branch mit in den Statistiken https://www.openhub.net/p/friendica 2016 kommen danach im Schnitt pro Monat 200 Commits ins Repository.

    Was wohl unbestreitbar ist, der Anvisierte Termin für das 3.5er Release ist gerissen worden. Aber da gibt es Showstopper. Einige davon wurden bereits aus dem Weg geräumt.

    Du erwähnst ja selber das Support Forum, hast du da mal nachgefragt wie der Stand der Dinge ist?

    1. Jens Tautenhahn

      Vielen Dank für die erhellenden Infos. Es freut mich sehr, dass die Entwicklung von Friendica weiter geht und ich nur auf die falsche Auswertung geachtet habe. Das Supportforum konnte ich gestern leider nicht erreichen. Der entsprechende Server war zwar nicht tot, hat aber auch nicht geantwortet. Leider etwas symptomatisch für viele Friendica-Instanzen und auch oft nicht Schuld der Software. Ich jedenfalls werde die Entwicklung von Friendica gerne weiter beobachten.

  3. Michael

    Tobias hat es ja schon gesagt, der Master-Branch sieht tatsächlich mau aus, liegt aber einfach an der Arbeitsweise. Wir arbeiten auf dem Developer-Branch und erst beim Release werden die Änderungen in den Master-Branch übertragen.

    Im Developer-Branch sind sehr viele nette Dinge drin. Praktisch die gesamte Protokoll-Behandlung wurde neu erstellt, d.h. der Code für die Kommunikation mit Diaspora und Friendica ist komplett überarbeitet.

    Die "Worker"-Hintergrund-Verarbeitung ist produktionsreif. Sie soll die Verarbeitung von Prozessen im Hintergrund stabiler und weniger belastend für das System durchführen.

    Es gibt ein wunderhübsches neues Theme (Frio), das zwar noch nicht ganz komplett ist, aber schon jetzt benutzbar ist und um Klassen besser ist als alles, was wir bisher hatten.

    Zusammengefasst enthält das kommende Release viele interne Überarbeitungen, die das Gesamtsystem schneller und stabiler machen sollten.

    Es gibt noch kleine Probleme, die uns daran gehindert hatten, ein Release zu machen. Dies sind aber tatsächlich alles Dinge, die schon in vorherigen Versionen nicht so liefen wie erwartet.

    Wer Lust ja zu schauen, was wir die letzten Monate gemacht haben, hier ist die Commit-Historie:

    https://github.com/friendica/friendica/commits/develop

  4. Michael

    BTW: Aus welchem Grund hast Du Deinen Friendica-Server heruntergefahren? Zu den von Dir genannten Problemen:

    - Was für Probleme siehst Du bei UTF-8? Ich habe hier definitiv keine.
    - Zu den "neu Beitragenden": Insbesondere wegen der Konnektivität zu Diaspora kann ich mich definitiv über Langeweile beschweren :-)
    - Das Datenbankmodell wird schrittweise überarbeitet, die Performance auch für größere Datenmengen ist merklich gesteigert worden.
    - Was verstehst Du unter einer "genormten Schnittstelle für Plugins"? Welche Probleme siehst Du bei den Plugins?

    1. Jens Tautenhahn

      Vor Jahren schon einmal hatte ich massive Probleme mit Friendica und UTF-8. Ich hatte das auch mal in den Supportgruppen angesprochen. Allerdings war das Debugging dermaßen schwierig, dass ich es dann einfach so gelassen habe. Durch irgendeinen Commit lief es dann auch wie erwartet. Viel später habe ich für alle PHP-Projekte versucht, den gegenüber der damaligen PHP-Version extrem schnelleren HHVM zum Laufen zu bekommen. Hat ein paar Versionen von HHVM gedauert, aber dann lief auch Friendica ohne Probleme unter HHVM. Auch ohne UTF-8-Probleme. Jetzt habe ich zurückmigriert auf PHP, eine wirklich Standardinstallation von PHP-FPM + Nginx. Alle Umlaute werden wieder falsch in DB geschrieben... Das kann doch nicht sein, dass Friendica das nach Jahren nicht in den Griff bekommen kann. Mit einem externen DB-Tool sehe ich sehr gut, wie die Einträge zu alten PHP- und HHVM-Zeiten richtig in die DB eingetragen sind, jetzt aber mit einer Standardinstallation wieder das uralte Problem auftaucht. Ich betreibe auf dem Server noch ein paar andere Services. Alle anderen PHP-Projekte auf diesem Server haben dieses Problem nicht. Ok, vielleicht habe ich mit meiner Reaktion auch etwas übertrieben. Ich fahre den Knoten gerne wieder hoch und versuche zu debuggen, wo es denn wirklich hängt.

      Programmierer kochen alle nur mit Wasser. Ich weiß das aus eigenem Brötchenerwerb. Leider muss ich sagen, dass Friendica nicht gerade sparsam mit SQL-Abfragen umgeht. Auch wurde der Wildwuchs an Abfragen meiner Meinung nach bisher nicht behoben, sondern versucht durch Umstellung auf MyISAM, der Erstellung von haufenweise Indizes und (ganz schrechklich) dem periodischen OPTIMIZE von Tabellen noch ein paar Quentchen Geschwindigkeit herauszuholen. Die Benutzung moderne Datenbankeigenschaften wie z.B. referentieller Integrität oder auch Views fehlt vollkommen.

      Das sind nur ein paar der angesprochenen Probleme. Bitte versteht meine Kritik nicht als Kritik an eurer Arbeit, denn die ist Klasse und unterstützenswert! Mir ist bei den seit langem ungelösten technischen Problemen einfach nur der Hals geplatzt.

      1. Michael

        Ich kenne UTF-Probleme nur bei falschen PHP-, bzw. Datenbankeinstellungen. Das war auch schon mal Thema im Support-Forum. Innerhalb von Friendica werden die Daten lediglich weitergereicht, das wäre aber auch alles.

        Ich empfehle Dir den Umstieg auf InnoDB. MyISAM ist echt schrecklich. Bei den Indizes bin ich derzeit mal wieder dabei, Optimierungen durchzuführen. D.h. ich bin dabei, Queries umzustellen, so dass wir Indizes einsparen können. Es ist viel Erblast drin, aber wir schreiben derzeit viele Teile im Core um. Und da gab es im Develop-Branch viele Änderungen, die laut den Usern viel Geschwindigkeit gebracht hat.

        Das mit dem Optimize ist eine Unterstützung für Admins, die sich nicht selber um ihre Datenbank kümmern. Aber ich bin am Überlegen, das per Standard zu deaktivieren, da es Locking-Probleme bereiten kann.

        Dinge wie referentielle Integrität sind toll, aber leider laufen noch viele Installationen unter MyISAM. Da sind die Möglichkeiten arg beschränkt.

        Ich empfehle Dir den Umstieg auf den Develop-Branch. Das sollte helfen.

        1. Jens Tautenhahn

          InnoDB ist seit langer Zeit die Default-Engine bei mir. Auch Friendica lief seit langer Zeit darauf. Und dank "innodb_file_per_table = 1" hat sich das dauernde OPTIMIZE auch nicht so ganz gravierend auf das ansonsten immer größer werdende InnoDB-Datafile ausgewirkt. Ich kenne keine ernstzunehmende MySQL-Installation, die heutzutage nicht InnoDB anbietet. Vielleicht sollte man da mal umdenken.

          Einfach durchreichen reicht anscheinend nicht. Zumindest sollte Friendica überprüfen, wie die das Character-Set der Verbindung eingestellt ist, denn genau in diesem Character-Set liefert es dann Daten. Alternativ (vielleicht die bessere Variante) ist, mit "SET NAMES utf8;" gleich alles auf UTF-8 einzustellen. Das ist sozusagen die "Wunderwaffe" ;) Wie handhabt ihr das, wenn die Connection z.B. auf ISO-8859-1 läuft und chinesische Zeichen ankommen? Die werden ohne vorherige Einstellung doch niemals korrekt gespeichert.

          1. Michael

            BTW: Das Optimize lässt sich per Config deaktivieren.

            Was "SET NAMES utf8" angeht: Ich hab mich bislang noch nicht mit der Thematik beschäftigt. Ich werde mir jetzt mal "mysqli_set_charset" anschauen (das soll man ja stattdessen nutzen). Ich muss das sorgfältig testen und schauen, wie ich damit umgehen kann, wenn die Bestandsdaten kaputt sind.

            Es gibt viele Installationen da draussen, die auf MyiSAM laufen. Wir können das schlecht per Programmierung ändern. Was wir schon lange gemacht haben: Früher wurden die Tabellen automatisch als MyISAM angelegt. Heutzutage wird die Standardeinstellung des jeweiligen Datenbankservers verwendet, die hoffentlich InnoDB sein sollte.

            1. Jens Tautenhahn

              Ok, ich würde vorschlagen, dass wir das Thema in Friendica weiterführen. Der Knoten hier läuft wieder. Vor allem schon mal Danke für die vielen Tipps!

  5. Martin

    Ich gehe davon aus, dass Friendica sicher weiterentwickelt wird, wenn die Zeit kommt. Es gibt immer Zeiten da sind die Entwickler rar gezählt und machen Dinge vorrangig, womit sie Geld verdienen können. Für mich verständlich.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.