Da ist mir bekannt. Mir geht es eher um den Fall, dass ich mich nicht setzen kann oder nicht den Platz habe mich auszubreiten. Mein klassisches Szenario dafür ist ein (über)voller Zug.Benno007 hat geschrieben:Zu dem Tastaturproblem kann ich vorerst wenig beitragen, außer dass Bluetooth-Tastaturen unterstützt werden. Zumindest für sitzende Positionen habe ich auf die Schnelle diese hier gefunden:
http://www.computerworld.com/article/29 ... phone.html
Da sind schon kleine Bluetoothtastaturen unpraktisch, wenn man keine passende Hülle hat um Telefon und Tastatur fest miteinander zu verbinden, denn beides zusammen festzuhalten, zu tippen und dann auch noch auf Erschütterungen zu reagieren übersteigt meine akrobatischen Fähigkeiten.
Maemo ist von der Struktur her ein klassisches Debiansystem, mit ganz normal funktionierendem apt. Aber dass es seitens Nokia dort ebenfalls nur Backports und keine neuen Kernel gab ist genau das was es inzwischen immer schwieriger macht, die Plattform auch nur notdürftig aktuell zu halten. Das Hauptproblem für neuere Kernel aus Communityhand ist, dass es im Kernel proprietäre Treiber und Firmwares gibt, die wenn überhaupt, dann nur schwer mit neueren Kerneln zum Laufen zu bringen sind.Benno007 hat geschrieben:Der Kernel liegt hier wohl auch nur in einem Container vor, wird in dieser Version aber weiterhin mit nötigen Backports versorgt, damit z.B. der Bug zur Verschlüsselung gelöst werden könnte.
Meine begrenzten Erfahrungen mit Android 2.x zeichneten da kein besseres Bild. Deshalb bin ich da so skeptisch, denn von diesem Hick Hack unter Maemo habe ich ganz schön die Nase voll. Daher würde ich mich nur auf eine neue Plattform einlassen, wenn vorher geklärt ist, dass es da keine ähnlichen Hürden gibt.
Das kommt auf die Abhängigkeiten an. Was mir unter Maemo z.B. massiv auf die Füße gefallen ist war, dass die Jessie-glibc mindestens Kernel 2.6.32 voraussetzt. D.h. jede Software die darauf aufsetzt (was direkt oder indirekt eigentlich jede ist) bekommt Probleme mit dem Maemo-Kernel. Die Jessie-glibc lässt sich patchen um auch mit 2.6.28 noch klarzukommen, aber auf solche Sinnlos-Forks habe ich eigentlich keine Lust.Benno007 hat geschrieben:Terminal-Befehle laufen eigentlich auch ganz geschmeidig und sollten selbst außerhalb vom Container meist nicht so schnell einen neuen Kernel brauchen, oder?
Das ganze Problem würde nicht bestehen, wenn Nokia dafür gesorgt hätte, dass man einfach den Kernel aktualisieren kann.
Ein ähnliches Problem besteht eigentlich schon immer mit Pulseaudio. Aber das hat natürlich nicht so eine Tragweite.
Genau das ist die Frage über die ich aufgrund meiner Maemo-Erfahrung (das damals als so offen gelobt wurde) gern Klarheit hätte, und zwar vor dem Kauf und über das gesamte System. Hat sowas überhaupt schon mal jemand probiert?Benno007 hat geschrieben:Wenn du dir alle Quellcodes einzeln aus allen Paketquellen zusammenkratzt, sollte das sofort möglich sein.
Auch bei der Aussage schrillen bei mir aufgrund meiner Maemo-Erfahrung die Alarmglocken. Sind die "gerätespezischen Treiberpatches im Kernel" auf neue Kernel übertragbar oder an das ABI gebunden?Benno007 hat geschrieben:Der Quellcode ist, bis auf die üblichen gerätespezischen Treiberpatches im Kernel sowie gerätespezifisch vorinstallierte Apps [..] bei allen Grundapps und Grundsystem 100% verfügbar.
Und was sind in dem Zusammenhang "Grundapps"? Unter Maemo ist z.B. die Telefon-App nicht offen und die Schnittstellen sind nicht genug dokumentiert um selbst für Ersatz zu sorgen. Auf einem Telefon halte ich das für eine Grundapp.
Mir ist klar, dass du die Fragen nicht alle beantworten kannst, und das erwarte ich auch gar nicht. Das soll hier auch nur demonstrieren was in meinem Kopf abgeht wenn ich von einem "offenen" Smartphone höre. Und bevor diese Fragen nicht in meinem Sinne geklärt sind verspüre ich aufgrund meiner Erfahrungen nur noch wenig Elan, mich mit einem Gerät das als "Smartphone" beworben wird auch nur näher zu beschäftigen.
Klar kann man das alles mit viel Fleiß selbst in Erfahrung bringen. Viel einfacher wäre es aber, wenn der Geräteanbieter von vornherein klarmachen würde, dass JEDE Komponente auf seinem Produkt einem Kodex ähnlich dem DSC entsprechen muss. Dann kann ich als Anwender nämlich sicher sein, dass schon der Hersteller dafür sorgt, dass ich später die Wartung des Systems übernehmen kann, wenn er sich nicht mehr dafür interessiert.