Ich will hier nicht F-Droid i.A. oder spezifische Vor- oder Nachteile i.B. diskutieren. Nur diesen konkreten Punkt: Was ist das (an verschiedenen Stellen angemerkte) Problem mit alter (veralteter?) HW für ein Build-System bei F-Droid? Ich kann es bisher nicht wirklich als tatsächliches Sicherheitsproblem nachvollziehen. Ist die HW denn dort wirklich so alt (also dementsprechend „veraltet“!), dass sie das bloße Compilieren mit heute üblichen Compiler-Settings nicht unterstützt? Ich meine: es geht doch um Build (also Compile & Co) — nicht um das Ausführen. Ausführung von (eventuell modernem) Code auf alter HW könnte ich ja nachvollziehen. Aber der bloße Build-Prozess?
Das neue System zeigt bereits eine enorme Verbesserung. Die Statistiken der Laufzeiten der letzten zwei Monate deuten darauf hin, dass die vollständigen Build- und Publish-Aktionen viel schneller als zuvor erledigt werden. So haben wir beispielsweise in diesem Jahr zwischen Januar und September alle drei bis vier Tage Updates veröffentlicht, im Oktober dann alle zwei Tage, im November täglich und im Dezember sogar zweimal täglich.
Das Problem wurde im August letzten Jahres deutlich, nachdem Gradle, ein Build-Automatisierungstool, dass sehr viele - wenn nicht so ziemlich alle - Android(-App)-Entwickler benutzen auf Version 9 gehoben wurde. Die meisten seriösen Entwickler pflegen natürlich auch ihre Entwicklungssoftware, außerdem soll dieses Update auch einige Funktionen enthalten haben, auf die manche Entwickler sehr gewartet haben, so dass diese eben auch schnell auf Gradle 9 upgegradet haben. Gradle 9 bzw. das quasi zeitgleich veröffentlichte Android Gradle Plugin (AGP) 8.12.0 verlangt offenbar zwingend die CPU-Befehlssatzerweiterungen SSSE3 und SSE4.1, die zwischen 2006 und 2008 eingeführt wurden und seitdem in nahezu allen Intel-Prozessoren vorhanden waren und AFAIK so ab spätestens 2011 auch in allen von AMD.
Wir sprechen hier also zu diesem letztjährigen Zeitpunkt von ca. 14 oder 15 Jahre alter Hardware (wenn nicht gar noch älter). F-Droid selbst schrieb, dass ihr Build-Server 12 Jahre alt gewesen sein soll - und offenbar zu dem Zeitpunkt, als F-Droid ihn übernahm auch schon 7 Jahre auf dem Buckel hatte. Das führte dazu, dass einige Apps, deren Entwickler das Gradle-Update/Abhängigkeiten in ihren Quellcodes angepasst haben, eben in F-Droid zunächst keine Updates mehr bekommen hatten. Das hat bzw. hätte bedeutet, dass diese Entwickler entweder wieder auf vorige Gradle-Versionen downgraden mussten - und damit auch auf z.T. wichtige Features und Verbesserungen verzichten - oder extra für F-Droid zweigleisig fahren mit einer zusätzlichen downgraded Version - was natürlich deutlichen Mehraufwand bedeutet (hätte).
Alles in allem: Abgesehen von anderen aus Sicherheitsperspektive kritikwürdigen Aspekten bei F-Droid - die wir in diesem Thread zu recht - wie vom TO gewünscht - nicht diskutieren sollten, da es dazu bereits genug - auch in diesem Forum - gibt und den oben genannten Auswirkungen auf App-Entwicklung bezüglich neuer - auch sicherheitsreleavanter - Funktionen an sich, ist allein die Tatsache, dass solche Prozesse, wie das Kompilieren etlicher, einer breiteren Masse bereit zu stellender Apps auf solch alter Hardware an sich schon aus Sicherheitsperspektive zumindest kritisch zu sehen und wenig Vertrauen erweckend. Schließlich tauchen auch da immer wieder z.T. sehr kritische ausnutzbare Sicherheitslücken auf, die ein System angreifbar machen. Gerade bei Hardware sind die Support-Zeiträume für Firmware oft nicht so lang - zumindest selten länger als 5 Jahre - und wir sprechen hier von 12. Und auch, dass der Server bei Inbetriebnahme durch F-Droid auch schon 7 Jahre alt war.
Edit: @tulpenknicker war schneller (und kürzer ), wodurch sich hier einiges doppelt.
Damit ist die ursprüngliche Frage hier beantwortet.
Dieser Thread hier veranlasst mich, über die F-Droid Problematik erneut ernsthaft nachzudenken. Z.B.:
überhaupt Nutzung von F-Droid?
wenn Nutzung von F-Droid: primär (d.h. quasi vor allen anderen Quellen) ODER eben nur (unbedingt?!) nachgelagert?
alternative Nutzung von Izzy? (soll gewisse Unterschiede sowie Vor-/Nachteile haben)
möglichst alles abdecken mit Obtainium statt(!) F-Droid (oder auch Google Play)? (also nicht zusätzliche Nutzung von Obtainium lediglich für spezifische Fälle, sondern quasi alternativlos, wo immer möglich (klar, CSS (im Gegensatz zu OSS) i.d.R. ausschließlich per Google Play))
Ich habe mal ein paar alte Threads zusammengesucht.
), wodurch sich hier einiges doppelt.