From: Boris Kraut Date: Sun, 31 May 2015 13:47:34 +0000 (+0200) Subject: Android, ein Client-OS fuer Dumbphones X-Git-Url: http://git.marmaro.de/?p=krt-msg;a=commitdiff_plain;h=6e24615ea6ea5d17faed04470bbbcc7eea577248 Android, ein Client-OS fuer Dumbphones --- diff --git a/2015-05-31T13:47:31Z.msg b/2015-05-31T13:47:31Z.msg new file mode 100644 index 0000000..c79bc30 --- /dev/null +++ b/2015-05-31T13:47:31Z.msg @@ -0,0 +1,144 @@ +From: Boris Kraut +To: undisclosed-recipients: ; +Date: Sun, 31 May 2015 15:47:31 +0200 +Message-ID: <20150531154731.EfaPmu@edupad.local> +Reply-To: Boris Kraut +Subject: [.plan] Android, ein Client-OS fuer Dumbphones + +Vor einiger Zeit hat Google ein Drucker-Framework in Android integriert, +das nichts bietet ausser zwei definierte Schnittstellen -- in Richtung +Anwendungen und in Richtung Druckdienst ("-app"). Leider scheint es kaum +ein Interesse daran zu geben, von seinem Smartphone aus einen Drucker +im lokalen Netz anzusprechen -- zumindest nicht in standardisiert, offen, +frei: Es gibt zwar einiger Anwendungen von Drucker-Herstellern, die +natuerlich nur mit einer sehr begrenzten Auswahl an (eigenen) Druckern +sprechen koennen -- ebenfalls alle unfrei -- und auch ein paar Apps +von Drittanbietern, die aber aehnlich beschraenkt und geschlossen sind, +aber die grundsaetzliche Idee scheint zu sein, einen virtuellen Druck- +dienst in der Cloud zu nutzen, der dann bei Darf an einen lokalen Drucker +weiterleiten kann. Wie kaputt ist das denn? Ich schicke Daten von einem +lokalen Geraet in die Cloud, damit mein lokaler Drucker davon Drucken +kann? Seufz. + +Nun, Jon Freeman [0] hatte damals schon eine halbwegs funktionsfaehige +Anwendung, die per IPP (HTTP) lokale CUPS-Netzwerkdrucker ansprechen +konnte und wollte diese auf das neue Framework portieren. Leider musste +er das aber aus gesundheitlichen Gruenden aufgeben. Vor kurzem habe ich +mir die Muehe gemacht seinen alten Code auf Gradle zu portieren und +die verwendeten Binaerbibliotheken zu ersetzen bzw. direkt aus jCenter +zu holen. Das Ergebnis [1] ist jetzt auch in FDroid [2] zu finden, auch +wenn die UI grottig ist und nicht unter allen Umstaenden funktioniert. +Mir war es nur wichtig, dass wir endlich einen freien Druckerdienst fuer +Android haben und damit eine der letzten grossen Luecken schliessen. +Fuer mich ist damit ein Meilenstein erreicht: + +Zum ersten Mal decken wir damit nahezu alle Bereiche und Standards ab, +die ein reiner "Client" nach aussen hin abdecken sollte: + +* Mail (IMAP/SMTP/POP) [3] +* Kurznachrichten (TEL/XMPP) [4][5] +* Browser (HTTP) [6][7] +* Kontakte und Kalender (CalDAV/CardDAV) [8][9] +* Zeit (NTP) [10] +* Drucken (IPP/HTTP) [11] +* Feeds (RSS/ATOM/FEED/HTTP) [12] +* Dateizugriff (WebDAV/FILE/HTTP/SCP/SFTP) [13][14] +* Shell (SSH) [15] +* Telefonie (TEL/SIP) [16] +* VCS (GIT) [17] + +Nicht ganz zur selben Kategorie, aber fuer mich ebenfalls zu diesem +Milestone gehoerend sind Wetter- und Geodaten. Wo letzteres nicht +ueber passives GPS/GLONASS verfuegbar ist, muss es ueber CellID und +bekannte Accesspoints geschehen. Prinzipiell ist das in Android +schon standardmaessig integriert, mit dem UnifiedNlp [18] des microG- +Projekts gibt es aber die Moeglichkeit die jeweiligen Anbieter per +Plugin auszutauschen, also auch eine alternative oder gar freie +Datenbank dafuer zu nutzen -- ggf. mit Offline-Daten. Wetterdaten +sind idR zwar nicht ins System integriert, sondern nur ueber Apps +verfuegbar, doch nutzen die meisten Geraete die vorinstallierten +Google-Anwendungen dafuer. Bei freien Wetterapps [19] kann meist +auch eine freie Datenquelle gewaehlt werden. + +Damit kratzen wir dann auch schon an meinem zweiten Meilenstein fuer +Android: Lokale Anwendungen. Darunter fallen neben nuetzlichen Tools, +die komplett ohne Daten auskommen, auch Anwendungen, die auf lokalen +Daten arbeiten muessen. Waehrend viele (aeltere?) Anwendungen fuer +Linux explizit zwischen der Verarbeitung und der Bereitstellung von +Daten trennen -- ein MUA arbeitet auf lokalen Mails, ob diese per POP3 +oder IMAP oder XYZ eingeliefert werden und welche Programme dafuer +zustaendig sind, ist ihm egal --, es also mehrere Tools gibt, die +zusammenarbeiten, hat sich bei Android der monolithische Ansatz fast +komplett durchgesetzt. Die positiven Ausnahmen sind vorgefertigte +Schnittstellen wie SMS, Anruflog, Kalender und Kontaktdaten. Manchmal +wuenschte ich mir, dass Google von vorherein bei Android auch an ein +Sotrage fuer Mail gedacht haben sollte... aber da ich weiss, wie lax +die Leute mit Berechtigungen umgehen, ist ein app-spezifischer Speicher +evtl. doch besser. Wie dem auch sei, noch bin ich mir nicht sicher, ob +es eine direkte Folge oder der Ausloeser ist, aber bei vielen Apps ist +eine rein lokale Nutzung nicht vorgesehen. Nutzen mehrere Apps die +selben Daten, muss ich die Accountdaten in jeder App einzeln angeben +oder alle Entwickler dazu bringen eine noch zu schaffende gemeinsame +Schnittstelle zu nutzen. + +Prinzipiell denke ich, dass wir mit freien Anwendungen eine rudimentaere +offline Nutzung ermoeglichen koennen. An vielen Ecken und Enden fehlt es +jedoch noch an wenigen, aber wichtigen Kleinigkeiten. Das ist aber +kein Problem der freien Software, sondern ist dem generellen "Mindset" +der meisten Android-Entwickler geschuldet: Android ist per Design +ein Dumbphone in dem Sinne, dass es konstruiert wurde, um sich mit +anderen Diensten zu verbinden, nicht um offline zu arbeiten. + +Meine beiden letzten Meilensteine habe ich schon nahezu aufgegeben: +Server-Software und freie Treiber/Firmware. Waehrend die meisten bei +letzteren wenigstens noch den Sinn sehen, interessiert sich eigentlich +kaum jemand fuer Server-Software. Ich finde das ist ein fataler Fehler. +Ja, Android ist als Client konstruiert. Aber es geht auch gar nicht +darum, Android jetzt in Racks gepackt in Rechenzentren zu karren. Nein, +es geht eher um kleine Serverdienste fuer den Heimgebrauch, z.B. ein +abgespeckter IMAP-Server, der den fehlenden LocalStorage fuer Mails +bereitstellt, ohne dass die eigentlichen "Apps" angepasst werden +muessen. Ausserdem ist klar, dass eine Versteifung auf "Client" ein +fataler Fehler sein wird, wenn die dazugehoerigen (proprietaeren) +Serverdienste wegfallen... oder gar das zur Kommunikation noetige +Netz ausfaellt, bewusst manipuliert (Drosselung, Sperren, DPI..) +wird und generell nicht mehr vertrauenswuerdig ist: Ein Szenario +das gerade durch die Enthuellungen von Snowden immer greifbar wird +und meinem Tenor entspricht: Wir bauen unsere Zukunft auf eine +ziemlich bruechige Technologie, "always on" ist noch in weiter Ferne +(und evtl. auch gar nicht wuenschenswert). Das GuardianProject [20] +setzt daher vermehrt auf Pico- und Peer2Peer-Netze: Der FDroid-Client +hat dank Ihrer Hilfe eine Option, um sich selbst zum Server zu machen +und lokal installierte Anwendungen fuer FDroid-Nutzer im selben Netz +freizugeben [21] -- die FDroid-APK selbst kann per Bluetooth verteilt +werden. Ausserdem entwickeln sie neben einem XMPP-Client auch einen +reinen Bluetooth-Broadcast-Chat [22]. Bei der ganzen Debatte um Ver- +schluesselung wurde leider vergessen, dass es Situationen gibt, +in der man nicht Verschluesseln will, sondern jeden potentiellen +Nutzer erreichen will. Ein kaputtes Netz oder ein unter fremder +Kontrolle stehender Service darf uns nicht vom Kommunizieren abhalten. + + +[0] http://mobd.jonbanjo.com/jfcupsprintservice/ +[1] https://github.com/krt16s/jfcups-service +[2] https://f-droid.org/forums/topic/cups-print-app/ +[3] https://f-droid.org/repository/browse/?fdid=com.fsck.k9 +[4] https://f-droid.org/repository/browse/?fdid=eu.siacs.conversations +[5] https://f-droid.org/repository/browse/?fdid=org.smssecure.smssecure +[6] https://f-droid.org/repository/browse/?fdid=org.mozilla.fennec_fdroid +[7] https://f-droid.org/repository/browse/?fdid=acr.browser.lightning +[8] https://f-droid.org/repository/browse/?fdid=at.bitfire.davdroid +[9] https://f-droid.org/repository/browse/?fdid=org.dmfs.tasks +[10] https://f-droid.org/repository/browse/?fdid=org.ntpsync +[11] https://f-droid.org/repository/browse/?fdid=com.jonbanjo.cupsprintservice +[12] https://f-droid.org/repository/browse/?fdid=net.etuldan.sparss.floss +[13] https://f-droid.org/repository/browse/?fdid=com.owncloud.android +[14] https://f-droid.org/repository/browse/?fdid=com.ghostsq.commander +[15] https://f-droid.org/repository/browse/?fdid=org.connectbot +[16] https://f-droid.org/repository/browse/?fdid=org.lumicall.android +[17] https://f-droid.org/repository/browse/?fdid=me.sheimi.sgit +[18] https://f-droid.org/repository/browse/?fdid=com.google.android.gms +[19] https://f-droid.org/repository/browse/?fdid=ru.gelin.android.weather.notification +[20] https://guardianproject.info/ +[21] https://dev.guardianproject.info/projects/bazaar/wiki +[22] https://github.com/n8fr8/gilgamesh/