SHIFT6mq pläne nach Qualcomm Chip "end of support" termin?

faird

Member
Original poster
Sep 20, 2018
12
Der Chip des 6mq ist ja nun schon was älter (release 2018). Ich weiss nich genau wann qualcomm den support einstellt, aber es sind definitv nicht mehr als 4 jahre bis es keine blobs mehr gibts, also baumelt das schwert schon wieder über dem telefon. Fairphone hat das selbe problem gehabt und nach 3 jahren oder so anfangen müssen einen eigenen kernel zusammenzustückeln. Würde mich nun fragen was bei shift ab Tag X passieren soll, denn das versprechen das phone bis 5 jahre zu unterstützen war einer der größten punkte warum ich mich damals für fp2 entschied (das mein erstes smartphone nach dem ich es 1.5 jahre nach release kaufte schon keine patches mehr bekam hat weh getan und lässt mich einen weiten bogen um alles bei dem mediateck verbaut wurde machen).
 

Diogenes

Member
Jun 14, 2018
41
Was ich grundsätzlich nicht verstehe ist, warum bei einer neuen Betriebssystemversion neue Treiber nötig werden. Die Hardware ändert sich ja nicht. Im Normalfall wird nur das OS mit sinnvollen oder sinnlosen Funktionen erweitert bzw aufgeblasen.
Dieses ständige "neue Treiber" Problem hat für mich das extreme Geschmäckle einer geplanten Obsoleszenz.
Ließe sich das durch eine einmal zu erfindende Treiber-VM nicht endgültig aus der Welt schaffen? Bei der dann je nach OS nur mehr die Übergabestellen vom/zum OS bei Versionsänderungen angepasst werden müssen. Die Treiber könnten dann aus dem Jahre Schnee stammen.
 
  • Like
Reactions: Martin S.

thht

Alpha Tester
Beta Tester
Jun 5, 2020
7
Eine neue Android Version bedeutet immer auch ein neuer Linux Kernel. Dadurch müssen alle Treibermodule neu gegen den neuen Kernel kompiliert werden. Auch ändern sich ab und zu die Schnittstellen.

Bei Treibern im Linux Kernel (sogenannt Mainline) ist das kein Problem, da die einfach mit neu kompiliert werden und bei der Entwicklung des Kernels auch darauf geachtet wird, dass die weiter laufen.

Bei den "out of tree" Treibern wird darauf nicht geachtet. Die müssen also jeweils neu kompiliert und auch angepasst werden. Bei Treibern, die komplett Open Source sind, ist das im Endeffekt Fleißarbeit, die aber machbar ist. Viele Treiber, die man für ein Smartphone braucht, vor allem alles, was im SOC steckt (CPU, GPU, diverse Controller) sind nicht Open Source. Häufig liegt ein Teil mehr oder minder frei als Sourcecode vor, braucht aber dann eine Binärdatei (genannt BLOB), der vom Hersteller jedes mal neu angepasst werden muss.
 

Diogenes

Member
Jun 14, 2018
41
Eine neue Android Version bedeutet immer auch ein neuer Linux Kernel. Dadurch müssen alle Treibermodule neu gegen den neuen Kernel kompiliert werden. Auch ändern sich ab und zu die Schnittstellen.

Bei Treibern im Linux Kernel (sogenannt Mainline) ist das kein Problem, da die einfach mit neu kompiliert werden und bei der Entwicklung des Kernels auch darauf geachtet wird, dass die weiter laufen.

Bei den "out of tree" Treibern wird darauf nicht geachtet. Die müssen also jeweils neu kompiliert und auch angepasst werden. Bei Treibern, die komplett Open Source sind, ist das im Endeffekt Fleißarbeit, die aber machbar ist. Viele Treiber, die man für ein Smartphone braucht, vor allem alles, was im SOC steckt (CPU, GPU, diverse Controller) sind nicht Open Source. Häufig liegt ein Teil mehr oder minder frei als Sourcecode vor, braucht aber dann eine Binärdatei (genannt BLOB), der vom Hersteller jedes mal neu angepasst werden muss.
In der Hinsicht ist also Microsoft bis zu einem gewissen Grad besser, da sich Treiber von Vista zum Teil in Win 7, 8 oder 10 verwenden lassen.
 

Diogenes

Member
Jun 14, 2018
41
Das ist ohne Zweifel korrekt. Schade dass sich dieses Plus von Windows nicht extrahieren und adaptieren lässt. Ich denke das hätte für viele Geräte massive Vorteile. Gerade mit Software ist geplante Obsoleszenz ein leichtes Spiel für die Hersteller.
 

MrPeak

Active member
Apr 24, 2020
66
Es ist ja auch so, dass so ein SoC (wie der Name schon sagt) viel umfänglicher ist als der klassische x86 PC, viel komplexer, wenn selbst das Ladeprotokoll des Akkus integriert ist. Und es gibt keine relevante Anforderung nach offenen Treibern welche eine kommerzielle Bedeutung für die Hersteller haben könnten. Letztendlich auch eine Richtung welche der Verbraucher durch sein Handeln vorgibt.
 
  • Like
Reactions: blackcat

Diogenes

Member
Jun 14, 2018
41
"Letztendlich auch eine Richtung welche der Verbraucher durch sein Handeln vorgibt "
Dem widerspreche ich grundsätzlich. Es gibt den Gesetzgeber um Regulierungen zu schaffen, von selbst fallen maximal Äpfel von Bäumen und als Konsument hast du praktisch nur die Wahl aus den Dingen die angeboten werden, nicht mehr. Bestes Beispiel: die Stecker an den Handys und Mobiltelefonen. Ursprünglich totales Chaos, jeder sein Süppchen und als Konsument musstest du nehmen was dabei war. Dann kam ein Gesetz und zack, überall ein Stecker außer bei Apple.
Um gegen die geplante Obsoleszenz effektiv vorzugehen müsste es z.B. ein Gesetz geben das nach Ablauf einer Frist (z.B. 6 Monate nach Supportende) ein veröffentlichen von relevanten Daten zur Treiberentwicklung unter Open Source erzwingt.
 

trainman261

Member
Sep 12, 2020
7
Zur Erklärung, wieso das mit den Updates bei Android nicht so leicht läuft: Auf dem PC ist es so, das es ein standardisiertes System gibt, wie die Rechner hochfahren und mit der Hardware kommunizieren. Da hatte man den Bios, jetzt hat man UEFI, aber das ist dennoch ein Baukastensystem, wo jeder auch noch sein Bauteil hinzufügen kann.
Dasselbe gilt dafür, wie Windows mit der Hardware kommuniziert. Man hat einmal Windows, und dann die unterschiedlichen Treiber. Windows wird mit ein paar grundsätzlichen Treibern geliefert (deswegen ist es z.B. bei einer Grafikkarte so, dass bevor man die Treiber installiert, wird alles in einer ganz niedrigen Auflösung angezeigt - das ist der mitgelieferte Treiber, der eben nicht so viel kann), damit man das System in Schwung bringen kann, und für das Meiste werden dann die Treiber-"Module" verwendet. Wenn Windows ein Upgrade macht, wird geschaut, dass die Schnittstelle zwischen Windows und den Treibern möglich gleich bleibt, und damit keine Probleme entstehen (obwohl das in der letzten Zeit auch nicht so toll gelaufen ist).
In Linux ist es so, dass die meisten Treiber im Kernel mitgeliefert werden, und dann können weitere Firmen trotzdem noch eigene Treibermodule daran anschließen - ist allerdings eher die Ausnahme als die Regel (NVIDIA ist so eine Ausnahme). In der Regel ist wie gesagt der ganze Code für die Treiber im Kernel und open source. Damit wird gleich bei einer Kerneländerung darauf geachtet, dass die ganzen Treiber noch kompatibel bleiben, und wenn etwas nicht passen sollte, kann auch der Treibercode angepasst werden (ist ja alles open source).
In Android ist es dagegen so, dass dort nicht der Standard-Kernel von Linux verwendet wird. Dafür werden die Treiber geschrieben vom Hersteller (z.B. Qualcomm), diese werden allerdings nicht veröffentlicht. Stattdessen werden die Treiber kompiliert gegen der entsprechenden Android-Kernel-Version. Das Resultat ist ein "binary blob", was verwendet wird um den Android-Kernel für das einzelne Handy gesamthaft zu kompilieren. Erstmal alles gut, der Treiber wurde für das entsprechende Android-Kernel geschrieben, da passt alles. Dann kommt aber ein neuer Android-Kernel, aber man kann jetzt nur auf gut Glück versuchen, den mit dem vorherigen "binary blobs" zu kompilieren, was aber nicht funktionieren muss. Und wenn es dann nicht funktioniert, weiß man kaum wieso, weil diese "binary blobs" so ziemlich schwarze Boxen sind. Heißt, man muss raten, "was genau könnte der Grund sein, wieso das nicht funktioniert?", und auf der Basis irgendwie versuchen, das Ganze zum Funktionieren zu bringen.
Wieso sind die Systeme dann anders? Ganz einfach: PCs stammen aus einer Zeit, wo es noch normal war, dass man den Rechner gekauft hat, und ein Betriebssystem dazu separat. Da musste das Betriebssystem von Grund auf mit unterschiedlicher Hardware klarkommen, und die Hardware mit unterschiedlichen Betriebssystemen. Das hat sich dann einfach weiterentwickelt. Android dagegen ist ein Betriebssystem, was ursprünglich für Digitalkameras erstellt wurden ist, und der Linux-Kernel wurde einfach verwendet, damit sie den Kernel nicht neu schreiben mussten. Und na ja, wer will denn auf der Digitalkamera ständig Updates installieren, und wozu würde man so etwas brauchen. Da würde auch keiner erst auf der Kamera ein Betriebssystem und dann Treiber installieren wollen.
Wo Android dann auch auf Handys gelandet ist, hat Google erstmal gemeint, "ach, das mit dem Updaten und so können doch die Hersteller übernehmen, wir kümmern uns um das Betriebssystem, dann kommt es beim Nutzer als Gesamtpacket vom Hersteller an". Außerdem gab es das große Negativbeispiel von Apple in der Hinsicht, da sah es bei Android schon sehr gut aus, weil das alles offen und open source war. In der Zwischenzeit hatte Google die unterschiedlichste Ideen, wie sie die Hersteller dazu bringen konnten, die Updates auch durchzuführen (Versprechen von Unternehmen einzuholen, Firmen beschämen, usw.), hat aber nichts wirklich geklappt. Jetzt ist Google mit Project Treble auf dem Weg das zu modularisieren, sodass es eben ähnlicher ist wie Windows, mal schauen, wie das läuft. Ausgeliefert wird aber Android trotzdem noch als Gesamtpaket und nicht als Betriebssystem + Treiber, bzw. es ist so nicht möglich Android als Betriebssystem + Treiber auszuliefern, weil Android dafür nicht aufgebaut ist.
 

MrPeak

Active member
Apr 24, 2020
66
"Letztendlich auch eine Richtung welche der Verbraucher durch sein Handeln vorgibt "
Dem widerspreche ich grundsätzlich. Es gibt den Gesetzgeber um Regulierungen zu schaffen, von selbst fallen maximal Äpfel von Bäumen und als Konsument hast du praktisch nur die Wahl aus den Dingen die angeboten werden, nicht mehr. Bestes Beispiel: die Stecker an den Handys und Mobiltelefonen. Ursprünglich totales Chaos, jeder sein Süppchen und als Konsument musstest du nehmen was dabei war. Dann kam ein Gesetz und zack, überall ein Stecker außer bei Apple.
Um gegen die geplante Obsoleszenz effektiv vorzugehen müsste es z.B. ein Gesetz geben das nach Ablauf einer Frist (z.B. 6 Monate nach Supportende) ein veröffentlichen von relevanten Daten zur Treiberentwicklung unter Open Source erzwingt.

Ich verstehe deinen Widerspruch nicht. Eine Regulierung ist eine weitere Möglichkeit unabhängig von einem kommerziellen Handeln, erzeugt durch Nachfrage des Verbrauchers. Das eine schliesst das andere ja nicht aus. Nicht das ich falsch verstanden werde, ich halte Regulierungen an vielen Stellen für durchaus notwendig und sinnvoll.