staging.inyokaproject.org

Gibt es eine Möglichkeit das Ubuntu-Touch gegen ein "echtes" Ubuntu auszutauschen?

Bis jetzt habe ich immer nur gelesen, dass Ubuntu-Touch von "Android", wegen den Libs und sonstigem Gedöns, "abhängig" ist.

Das "Touch-Display" ist ja nur eine vergrößerte Maus.

Was ist mit dem echten Ubuntu für ARM (12.04 Release)?!

https://wiki.ubuntu.com/ARM

Will oder kann man das nicht (mehr) portieren? 😕

PS: Wie geil, eine betreffende Frage wurde schon 2013 gestellt und wurde nicht beantwortet ...! :

Any one can help answer the real differences between Ubuntu touch vs Ubuntu Unity Desktop, apart from touch function?

http://irclogs.ubuntu.com/2013/08/05/%23ubuntu-touch.html

Zu allererst ist das größte Problem von einem normalen Desktop die Touchfähigkeit. Auch wenn Unity schon einige Änderungen hat, damit man dieses per Touch bedienen kann, sind noch sehr sehr viele Programme 0 darauf ausgelegt und somit bringt dir alleine eine laufender Desktop erstmal nichts.

Dazu kommt noch das riesige Problem, dass wir bei der ARM Hardware keine generischen Treiber haben wie das auf der PC Hardware der Fall ist. Treiber gibt es hier meistens nur als Binäre-Blobs und diese sind dann an eine gewisse Android Version/Kernel gebunden. Einen freien nouveau Treiber, der für alle Kernel und nvidia Grakas funktioniert, gibt es schlicht nicht.
Daher setzt ubuntu-touch darauf, die Android-Treiber in Containern als Brücke einzusetzen: https://developer.ubuntu.com/static/devportal_uploaded/136981fa-6287-49d3-9874-06f40b2e4eb7-cms_page_media/380/ubuntu_touch_architecture.png

Das "normale" ubuntu-arm gibt es nach wie vor: https://wiki.ubuntu.com/ARM
Die Paketserver bauen auch alle Pakete für ARM, bis auf die Pakete, die nur für PC sind, wie Treiber und so kram. Es gibt für die vielen ARM-Boards auch eigene Images. z.B. für den rpi2: https://ubuntu-mate.org/raspberry-pi/

Also zusammengefasst:
Ubuntu-touch nutzt das Android-Gedöns um überhaupt auf der Hardware zu laufen, weil die Hersteller nur Android Treiber bereitstellen.
Ein normales Ubuntu(-Arm) macht auf einem Smartphone eh keinen Sinn, da die Anwendungen nicht mit touch-only umgehen können.
Portieren ist eh eine Aufgabe, die für 99,99% der User vollkommen überfordernd ist: https://developer.ubuntu.com/en/start/ubuntu-for-devices/porting-new-device/ und für ARM Boards: https://wiki.ubuntu.com/ARM#How_do_i_build_an_armel_rootfs_from_scratch

P.S.: das wurde dir aber sehr sehr ausführlich schon mehrere Male erklärt. Schau alleine mal in die logs von #ubuntu-arm vom 22.10.2014

Zumal ich Unitiy nicht mag - mir gefällt das Bedien-Konzept von Ubuntu-Touch!

Ein Betriebssytem auf allen Geräten - das hat MS vorgemacht. Die Lösung fand ich garnicht mal so schlecht, aber es ist halt je HW-Architektur immer ein Kompromis. Sprich: Die Lösung war gut, aber offenbarte gerade dadurch, dass die zugrundeliegende Idee schecht war. (Win10 ist ein ganz anderes Thema und kommt mir nicht ins Netzwerk). Ich kann auf meinem Win8 Tablet (ja, soetwas besitze ich) meine Textverarbeitung per Touch bedienen (ich benutze weder OO, LO noch MSO). Zum Korrekturlesen ist das super, nur funktioniert es lediglich halbherzig. Spätestens wenn ich ins Menü muß fehlen Evolutionsstufen (Finger schmaler oder Software anpassen). Hier ist mein Notes 8 mit Stifteingabe und KritziKratzi in PDF fantastisch, aber leider Android und Samsung.

Warum eigentlich liefern nicht die HW-Hersteller gut dokumentierte Schnittstellen? Die müssen ja nicht einmal offen sein. Es genügt, dass ich sie mit einem beliebigen standardconformen Compiler (C/C++/JavaC 😛 ) verwenden können.

Da dies nicht der Fall ist finde ich das das Konzept auf den bestehenden 'Vorgaben' der Hersteller aufzusetzen zunächst sehr gut. Sprich: Die Abängigkeit zu Android gefällt mir nicht, aber sie ist strategisch gut.

Jetzt noch ein (so hoffe ich) ordentliches Desig in Ubuntu Touch und Marktanteile gewinnen, dann können Abhängigkeiten vielleicht nach und nach modularisiert und abgelöst werden.

So wie ursprünglich bei Linux - bei 0 anfangen - das wäre heutzutage jedenfalls noch unrealistischer als damals 😉

k1l schrieb:

Dazu kommt noch das riesige Problem, dass wir bei der ARM Hardware keine generischen Treiber haben wie das auf der PC Hardware der Fall ist.

Wieso PC, hier geht es um ARM und nicht um X86 oder X64.

Treiber gibt es hier meistens nur als Binäre-Blobs und diese sind dann an eine gewisse Android Version/Kernel gebunden. Einen freien nouveau Treiber, der für alle Kernel und nvidia Grakas funktioniert, gibt es schlicht nicht.

Von nvidia hab ich auch nichts geschrieben. Vielleicht solltet "ihr" mal MTK auf die Füße treten.

Daher setzt ubuntu-touch darauf, die Android-Treiber in Containern als Brücke einzusetzen: https://developer.ubuntu.com/static/chitecture.png

Genau das will ich nicht! Wir sind bei Kernel 4.2 und wo dumpelt das Ubuntu-Touch Device rum? Android hat in einem reinem Linux-System nichts zu suchen. Android ist ein Linux "Derivat" und hat m.E. nichts in einem Linux-OS zu suchen.

Das "normale" ubuntu-arm gibt es nach wie vor: https://wiki.ubuntu.com/ARM Die Paketserver bauen auch alle Pakete für ARM, bis auf die Pakete, die nur für PC sind, wie > Treiber und so kram. Es gibt für die vielen ARM-Boards auch eigene Images. z.B. für den rpi2: https://ubuntu-mate.org/raspberry-pi/

Weder habe ich PCs (x86_64) noch einen RasperryPi angesprochen ...

Also zusammengefasst: Ubuntu-touch nutzt das Android-Gedöns um überhaupt auf der Hardware zu laufen, weil die Hersteller nur Android Treiber bereitstellen. Ein normales Ubuntu(-Arm) macht auf einem Smartphone eh keinen Sinn, da die Anwendungen nicht mit touch-only umgehen können.

Das sagst du. Ich habe kein Problem damit, mein Touch-Device mit einem Stift zu bedienen.

Portieren ist eh eine Aufgabe, die für 99,99% der User vollkommen überfordernd ist: https://> developer.ubuntu.com/en/starng-new-device/ und für ARM Boards: https://wiki.ubuntu.com/ARM#How_do_is_from_scratch

Wieso eigentlich portieren, sollte das nicht "standardmäßig" mit einem ARM (v7)-Device funktionieren? Falls nicht, warum gibt es keine Hardware (Device) -Liste für Ubuntu (LTS) -ARM?

P.S.: das wurde dir aber sehr sehr ausführlich schon mehrere Male erklärt. Schau alleine mal in die logs von #ubuntu-arm vom 22.10.2014

Tja, und das wurde nie beantwortet!

Ihr könnt euch nicht vor den Usern "verstecken"! Es sei denn, es ist euch "egal" !

@duno ... was meinst Du denn mit 'ihr'? OpenSource lebt vom 'wir'.

duno schrieb:

k1l schrieb:

Dazu kommt noch das riesige Problem, dass wir bei der ARM Hardware keine generischen Treiber haben wie das auf der PC Hardware der Fall ist.

Wieso PC, hier geht es um ARM und nicht um X86 oder X64.

Weil du dir das immer so einfach vorstellst, wie es bei deinem Laptop ist. Das es bei ARM anders ist haben dir sehr viele bisher vergeblich versucht bei zu bringen. Siehe meine Erklärung unter diesem Abschnitt.

Treiber gibt es hier meistens nur als Binäre-Blobs und diese sind dann an eine gewisse Android Version/Kernel gebunden. Einen freien nouveau Treiber, der für alle Kernel und nvidia Grakas funktioniert, gibt es schlicht nicht.

Von nvidia hab ich auch nichts geschrieben.

Das war ein Beispiel mit dem nvidia Treiber um es dir nochmal zu verdeutlichen.

Vielleicht solltet "ihr" mal MTK auf die Füße treten.

Es versuchen sehr viele Leute MTK dazu zu bewegen ihre Quellen offen zu legen. Das interessiert MTK aber nicht, so lange ihr Geschäft läuft. Warum jetzt aber "wir" das machen müssen solltest du mal genau erklären.

Daher setzt ubuntu-touch darauf, die Android-Treiber in Containern als Brücke einzusetzen: https://developer.ubuntu.com/static/chitecture.png

Genau das will ich nicht!

Was du willst ist erstmal vollkommen wumpe. Es sei denn du bezahlst dafür, dass MTK die Quellen der Treiber raus rückt oder eine Horde an Entwicklern, die das reverse engineeren.

Wir sind bei Kernel 4.2 und wo dumpelt das Ubuntu-Touch Device rum?

"Wir", das nächste ubuntu 15.10 kommt im Oktober und wird den 4.2er kernel haben. Ein Problem sehe ich hier nicht.

Android hat in einem reinem Linux-System nichts zu suchen. Android ist ein Linux "Derivat" und hat m.E. nichts in einem Linux-OS zu suchen.

Ich habe die erklärt warum der Aufbau ist wie er ist. Wenn du das anders willst dann TU was oder bezahle dafür. Aber von dir kommt nichts von beidem also bringt uns das so nicht weiter.

Das "normale" ubuntu-arm gibt es nach wie vor: https://wiki.ubuntu.com/ARM Die Paketserver bauen auch alle Pakete für ARM, bis auf die Pakete, die nur für PC sind, wie > Treiber und so kram. Es gibt für die vielen ARM-Boards auch eigene Images. z.B. für den rpi2: https://ubuntu-mate.org/raspberry-pi/

Weder habe ich PCs (x86_64) noch einen RasperryPi angesprochen ...

Ich habe es nochmal beschrieben. Du hattest den Eindruck erweckt, dass es das nicht mehr gibt.

Also zusammengefasst: Ubuntu-touch nutzt das Android-Gedöns um überhaupt auf der Hardware zu laufen, weil die Hersteller nur Android Treiber bereitstellen. Ein normales Ubuntu(-Arm) macht auf einem Smartphone eh keinen Sinn, da die Anwendungen nicht mit touch-only umgehen können.

Das sagst du. Ich habe kein Problem damit, mein Touch-Device mit einem Stift zu bedienen.

Dann portiere doch einfach mal ein Desktop Enviroment. Selbst wenn du es schaffen würdest (s.u.), wärst du sehr enttäuscht.

Portieren ist eh eine Aufgabe, die für 99,99% der User vollkommen überfordernd ist: https://> developer.ubuntu.com/en/starng-new-device/ und für ARM Boards: https://wiki.ubuntu.com/ARM#How_do_is_from_scratch

Wieso eigentlich portieren, sollte das nicht "standardmäßig" mit einem ARM (v7)-Device funktionieren?

Wie oft denn noch? NEIN! Es gibt kein " ich installiere einfach mal ein OS auf ein ARM device". Aber anstatt oben zu lesen, wo ich erklärte warum das so ist, meckerst du nur, dass es dir nicht in den Kram passt. Egal wie oft du diese Frage wiederholst, die Antwort wird sich nicht ändern, nur weil du das noch zig mal wieder fragst.

Falls nicht, warum gibt es keine Hardware (Device) -Liste für Ubuntu (LTS) -ARM?

Gibt es: https://wiki.ubuntu.com/ARM/DeviceSupport

P.S.: das wurde dir aber sehr sehr ausführlich schon mehrere Male erklärt. Schau alleine mal in die logs von #ubuntu-arm vom 22.10.2014

Tja, und das wurde nie beantwortet!

Nein. Dir gefällt die Antwort nicht und deswegen tust du so als wenn es keine Antwort gab.

Ihr könnt euch nicht vor den Usern "verstecken"!

Wer versteckt sich? Die Entwickler sind sehr offen gegenüber feedback, fragen und Kritik. Aber wenn ein user immer wieder mit unrealistischen Forderungen auf die nerven geht und schlicht behauptet seine Frage würde nicht beantwortet (nur weil ihm die Antwort nicht passt) dann hat eben keiner mehr Bock mit diesem user zu kommunizieren.

Es sei denn, es ist euch "egal" !

S.o.

Ich schreibe das jetzt mal aus meiner Sicht, obwohl k1l eigentlich schon alles gesagt hat.

duno schrieb:

Wieso PC, hier geht es um ARM und nicht um X86 oder X64.

ARM ist kein einheitlicher Standard. Es gibt die Architekturen ARMv1 bis einschließich ARMv8, und als ob das nicht genügen würde kann jeder Chiphersteller auch noch dutzende Erweiterungen dafür entwickeln. ARM ist nämlich eben nicht das, was x86 bzw. x86_64 für den PC darstellt, sondern hier kann jeder Hersteller, basierend auf einer Plattform, seine eigene, "neue" Plattform zusammenstellen. Und die Treiber dafür kommen von diesen Herstellern, meist auf eine bestimmte Kernelversion festgelegt. D.h. einfach mal ein Upgrade durchführen ist nicht drin, zumal auch die Schnittstellen nicht sauber definiert geschweige denn überhaupt öffentlich dokumentiert sind.

Daher setzt ubuntu-touch darauf, die Android-Treiber in Containern als Brücke einzusetzen: https://developer.ubuntu.com/static/chitecture.png

Genau das will ich nicht!

Genau das ist aber die einzige effiziente Möglichkeit, so ein Gerät mit Ubuntu zu nutzen. Wie willst du die ganze Hardware denn sonst dazu bringen, etwas zu tun? Klar, der eigentliche Prozessor wird von Linux unterstützt. Das bedeutet aber nicht, dass damit dann auch die FPU, Hardwaredekoder, WLAN, Bluetooth, NFC oder der Grafikchip unterstützt werden.

Ohne Treiber müsste sogar das komplette Rendering der grafischen Oberfläche in Software erfolgen. Dafür sind die verbauten CPUs allerdings nicht ausgelegt. Folge: Es ruckelt, der Prozessor läuft unter Volllast, die Akkulaufzeit geht gegen null.

Wir sind bei Kernel 4.2 und wo dumpelt das Ubuntu-Touch Device rum?

Kernel 4.2 ist erst vor kurzem herausgekommen, das dauert sowieso eine Weile, bis der Kernel in die einzelnen Distributionen wandert.

Android hat in einem reinem Linux-System nichts zu suchen.

Was ist denn ein "reines Linux-System"? So etwas gibt es nicht, Linux ist nur der Kernel.

Android ist ein Linux "Derivat" und hat m.E. nichts in einem Linux-OS zu suchen.

Diese Aussage ist vollkommen unsinnig. Android IST ein Linux basiertes Betriebssystem. Punkt.

Das "normale" ubuntu-arm gibt es nach wie vor: https://wiki.ubuntu.com/ARM Die Paketserver bauen auch alle Pakete für ARM, bis auf die Pakete, die nur für PC sind, wie > Treiber und so kram. Es gibt für die vielen ARM-Boards auch eigene Images. z.B. für den rpi2: https://ubuntu-mate.org/raspberry-pi/

Weder habe ich PCs (x86_64) noch einen RasperryPi angesprochen ...

Stell dir vor, die Pakete laufen nicht nur auf dem Raspberry Pi sondern auf allen ARM-Architekturen >= ARMv6. Wie man die Pakete auf das Gerät bekommt, damit Ubuntu auch bootet, ist wieder eine andere Frage. Achja, und natürlich die Sache mit den Treiber und den gerätespezifischen Anpassungen…

Das sagst du. Ich habe kein Problem damit, mein Touch-Device mit einem Stift zu bedienen.

Deswegen war auch die Microsoft Windows XP Tablet Edition ein solcher Erfolg. Oh, warte, das ging total in Hose.

Wieso eigentlich portieren, sollte das nicht "standardmäßig" mit einem ARM (v7)-Device funktionieren?

Die Software an sich: Ja. Aber bring das Ding mal dazu, zu booten. Und dann willst du natürlich auch die verbaute Hardware nutzen, und nicht alles via CPU wahnsinnig langsam berechnen. Have fun.

Ihr könnt euch nicht vor den Usern "verstecken"!

"Ihr"? Wenn willst du damit ansprechen?

Es sei denn, es ist euch "egal" !

Entwickler ignorieren neuerdings also Nutzer die nicht bereit sind geschriebenes zu lesen und zu verstehen?

Developer92 und k1l,

was ich total interssant finde, da ich ja nicht nur Ubuntu und Debian einsetze, sondern auch noch andere Linux-Embedded-Systeme betreibe, und keines von denen

ADB

unterstützt, egal ob MIPS, ARM, SH4 oder X86 (nonpae).

Würde mich mal interessieren, wie ich dieses ADB entferne, ohne gleich Ubuntu-Touch zu löschen.

Danke schon einmal für die Info vorab.

Genau das will ich nicht! Wir sind bei Kernel 4.2 und wo dumpelt das Ubuntu-Touch Device rum? Android hat in einem reinem Linux-System nichts zu suchen. Android ist ein Linux "Derivat" und hat m.E. nichts in einem Linux-OS zu suchen

öhm.. ein "reines" Linux ist nur der Kernel - nichts anderes.. da ist Android genau so Linux wie ein GNU/Linux.. und jedes Gnu/Linux ist ein Derivat (vielleicht mal abgesehen von Slackware und vielleicht Arch).. Ubuntu ist ja auch nur ein Derivat von Debian, welches wiederum ein Derivat von Softlanding Linux ist.

Wieso eigentlich portieren, sollte das nicht "standardmäßig" mit einem ARM (v7)-Device funktionieren? Falls nicht, warum gibt es keine Hardware (Device) -Liste für Ubuntu (LTS) -ARM?

weil ein Smartphone/Tablet eben nicht nur aus einem ARM Prozessor besteht, sondern da noch Wlan/Radio/Baseband dazukommt, das meist proprietär ist (entweder Qualcom oder Mediatek), dazu Audio, und Digitizer - alses proprietär.. daran muss man ein OS halt anpassen, sonst läuft es eben nicht

was ich total interssant finde, da ich ja nicht nur Ubuntu und Debian einsetze, sondern auch noch andere Linux-Embedded-Systeme betreibe, und keines von denen

ADB

ADB ist seit debian 8 in der Stable Repository zu haben

duno schrieb:

Developer92 und k1l,

was ich total interssant finde, da ich ja nicht nur Ubuntu und Debian einsetze, sondern auch noch andere Linux-Embedded-Systeme betreibe, und keines von denen ADB unterstützt, egal ob MIPS, ARM, SH4 oder X86 (nonpae).

Das müsstest du jetzt einmal näher erläutern. ADB ist doch auch für andere Systemarchitekturen kompilierbar, das sollte doch laufen.

Bzw.: Sprichst du jetzt vom adb Client oder Server?

Würde mich mal interessieren, wie ich dieses ADB entferne, ohne gleich Ubuntu-Touch zu löschen.

ADB ist elementarer Bestandteil. Mit Sicherheit kann man das irgendwie entfernen, ist allerdings nicht zu empfehlen (zumal es zur "Rettung" von Geräten unglaublich wertvoll sein kann, ebenso wie fastboot)

Er hat leider eine total unrealistische Vorstellung davon was ein Smartphone ist und was mit der Hardware und Software so passiert.

Und weil nicht alles so läuft, wie er sich das gerade wünscht sind ja alle anderen schuld, die sich die Hardware kaufen um sie so zu benutzen wie es gedacht ist.

ADB ist elementarer Bestandteil. Mit Sicherheit kann man das irgendwie entfernen, ist allerdings nicht zu empfehlen (zumal es zur "Rettung" von Geräten unglaublich wertvoll sein kann, ebenso wie fastboot)

hm, da ADB und Fastboot sogar selbst dann noch funktionieren, wenn kein Betriebsystem auf einem Smartphone ist (ADB dann natürlich nur rudimentär über das Recovery) kann man das nicht einfach "deinstallieren" - das ist Teil der SOC Firmware - das wird sehr schwer da was zu machen. Soweit ich mich auskenne sind HTCs die einzigen bei denen man die gesammte Bootloaderfirmware austauschen kann - aber ADB und Fastboot zu entfernen ist.. nun ja.. so als würde man bei einem Schiff die Rettungsboote entfernen

Developer92 schrieb:

duno schrieb: Das müsstest du jetzt einmal näher erläutern.

Naja, ich kenne das von anderen Embedded-Linux-Systemen mit NFS und TFTP. Aber ADB kommt da halt nicht vor um eine neue Firmware einzuspielen.

Das mit dem "Closed Source" hab ich schon verstanden, siehe u.A. Raspberry Pi, darum hatte es mich gewundert, dass es beim "Ubuntu-Phone" nicht genauso funktioniert ... da kann man vom Hersteller aus doch auch alles für den entsprechenden Kernel bauen, oder? 😕

duno schrieb:

Developer92 schrieb:

Das müsstest du jetzt einmal näher erläutern.

Naja, ich kenne das von anderen Embedded-Linux-Systemen mit NFS und TFTP. Aber ADB kommt da halt nicht vor um eine neue Firmware einzuspielen.

ADB ist eine relativ neue Entwicklung und wurde ursprünglich nur von Android-Geräten implementiert (daher auch der Name: Android Debug Bridge). Des Weiteren stellt ADB nicht nur eine Zugriffsmöglichkeit auf den Speicher dar (wie NFS oder TFTP), sondern ermöglicht auch das Ausführen von Befehlen.

Das mit dem "Closed Source" hab ich schon verstanden, siehe u.A. Raspberry Pi, darum hatte es mich gewundert, dass es beim "Ubuntu-Phone" nicht genauso funktioniert ... da kann man vom Hersteller aus doch auch alles für den entsprechenden Kernel bauen, oder?

Soweit ich weiß nicht. Allerdings kenne ich auch den aktuellen Stand bezüglich des Blobs für den Start des Betriebssystems sowie der Hardwaredekoder nicht.

Und es geht doch!

Beispiel bq Aquaris E4.5 Android-Version mit Lollipop

Was wird benötigt?

Rootrechte auf dem Android-Device

TWRPv2.8.7.1-Aquaris4.5(krillin).rar

Per MTK-Flash-Tools auf das Device schreiben und alternativ unter

http://www.mibqyyo.com/comunidad/discussion/50517/oficial-twrp-2-8-7-1-y-root-30062015-aquaris-e4-5/p1

nachlesen.

Eine in ext4 formatierte SD-Karte

Linux Deploy 1.5.5
https://github.com/meefik/linuxdeploy/releases

BusyBox 1.24.1
https://github.com/meefik/busybox/releases

Term.apk
https://jackpal.github.io/Android-Terminal-Emulator/

freebVNC-v3.7.9-final.apk
https://github.com/iiordanov/remote-desktop-clients/releases

Unter Android im Terminal als root

su -

mount -t ext4 /dev/block/mmcblk1p1 /sdcard

eingeben.

Bei linuxdeploy als Ziel /sdcard sowie z.B. 8192 (MB), also 8GB, als Größe angeben.

Als Benutzer und Passwort hab ich mal aus Spaß je phablet eingegeben.

Als Distribution Ubuntu 15.10 mit xfce auswählen.

Wenn alles durchgelaufen ist, noch per ssh

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:ubuntu-mozilla-security/ppa
sudo apt-get update
sudo apt-get install firefox thunderbird vlc libreoffice vim kodi

eingeben.

Jetzt könnt ihr soweit eigentlich alles installieren, was ihr vom Desktop her kennt.

Ansonsten ppa hinzufügen.

Per ssh funktioniert das eigentlich alles recht gut, leider bekomme ich das nicht per VNC zum Laufen.

Hat da jemand evtl. einen Tipp? 😕