1 From: Boris Kraut <krt@nurfuerspam.de>
\r
2 Date: Thu, 19 Sep 2013 17:45:32 +0200
\r
4 Message-ID: <20130919174532.payyfz@trauerweide>
\r
8 To: undisclosed-recipients: ;
\r
9 Subject: [.plan] Warum sind CLIs sich der Umwelt ihrer Nutzer nicht bewusst?
\r
10 Reply-To: Boris Kraut <krt@nurfuerspam.de>
\r
12 Insbesondere moderne Software wird von mir haeufig als "kaputte
\r
13 Technologie" bezeichnet, was haeufig verstoerte Blicke ausloest:
\r
14 weltfremder IT-Idiot. Menschen scheinen es nicht zu moegen, wenn
\r
15 man ihnen ihr neustes Spielzeug "weg nimmt" oder schlecht redet.
\r
16 Was andere in der Situation meist nicht verstehen ist, dass ich
\r
17 durchaus sehe, dass diese "kaputte" Technik ein Problem loest
\r
18 oder ein besonders wichtiges Feature bietet. Meine Kritik greift
\r
19 meist nur die konkrete Implementation an -- oder das Unverstaendis
\r
20 der eigenen Beduerfnisse.
\r
22 Schon lange muss ich mich darueber aergern, dass viele grafische
\r
23 Anwendungen mit verkrueppelter UI daherkommen, dass technische
\r
24 Voraussetzungen ohne Not gesetzt werden, dass eine saubere Trennung
\r
25 von Funkltionalitaet und UI bzw. Darstellung nicht erfolgt. Wie
\r
26 lange musste ich (und muss ich noch) z.B. darauf warten, dass
\r
27 Audiokommunikation keine Abhaengigkeiten auf Grafik hat? Ein Trend,
\r
28 der leider mit Tablets und browserzentrierten Arbeitsumgebungen
\r
29 immer weiter fortschreitet: Webcam, Mikrofon, Geodaten, uvm. Das
\r
30 alles steht der rein nutzenden Allgemeinheit schon lange zur Ver-
\r
31 fuegung -- und zum Glueck immer haeufiger auch in einer freien,
\r
32 standardisierten, weniger kaputten Form -- und darauf aufbauend
\r
33 entwickelten sich ganz neue Moeglichkeiten und Beduerfnisse. Auf
\r
34 einer Kommandozeile weiterhin haeufig undenkbar, was ich nach dem
\r
35 Ende meine Android-Versuche schmerzhaft lernte und vermisse.
\r
37 Praktisches Beispiel "Geodaten": Wenn ich einen Dienst wirklich
\r
38 auf meinem Smartphone genutzt habe, dann war es neben Kommunikation
\r
39 vorallem Navigation. Als erster Schritt dazu muss man natuerlich
\r
40 seinen eigenen Standort kennen. Wieso habe ich ein `date` Befehl,
\r
41 aber kein `position`? Bei mir gibt es den jetzt, er liefert eine
\r
42 Geo-URI des aktuellen Standorts zurueck. Momentan nutze ich dazu
\r
43 FreeGeoIp.net [0], aber in Zukunft werde ich Maxmind's GeoLite(2)-
\r
44 Datenbank [1][2] direkt und lokal nutzen -- ein ganz wichtiger
\r
45 Punkt: Wenig Abhaengigkeiten von externen Diensten. Da ich auch
\r
46 haeufig remote arbeite und dann nicht die Geoposition meines
\r
47 Servers wissen will, sondern die des Clients, wird vorher die
\r
48 Umgebungsvariable SSH_CLIENT ausgelesen und ggf. die dortige IP
\r
49 verwendet. Spaeter will ich auch WLAN-Daten zur Bestimmung nutzen,
\r
50 auch da gibt es einige offen zugaengliche Datenbanken, z.B. Open-
\r
51 WLAN-Map [4] und OpenBMap [3]. Letztere hat auch Handyzellen er-
\r
52 fasst. Als letzte Quelle waere da noch ein eigener GPS-Empfaenger,
\r
53 den man ueber den `gpsd` ansprechen kann. Zukunftsmusik.
\r
55 Ich bin uebrigens nichts der einzige (oder gar erste), der sich mit
\r
56 dem Thema beschaeftigt. Eigentlich ist das 'Problem' schon in etwas
\r
57 groesser geloest bzw. zumindest angegangen. Beispielsweise gibt es
\r
58 GeoClue [5] von FreeDesktop, das momentan auch nur GeoIP-Aufloesung
\r
59 macht, aber alle genannten Quell-Arten auch unterstuetzen will. Was
\r
60 die nutzen, um ihre Datenbank zu speisen (oder ob die da gar auch nur
\r
61 externe Services pollen -- Firefox nutzt imho z.B. standardmaessig
\r
62 Google's GeoAPI), weiss ich nicht. Muss ich mir mal anschauen. Um
\r
63 ehrlich zu sein: Das habe ich das erst gefunden, nachdem ich mich
\r
64 furchtbar ueber das Fehlen einer solchen Funktion aufgeregt, mein
\r
65 `position` Skript zusammengehackt und die ersten Paragraphen dieses
\r
66 Textes geschrieben habe :).
\r
68 Nun, was kann ich jetzt aber mit der GeoURI meiner aktuellen Position
\r
69 tolles anfangen? Neben den o.g. GeoProvidern braucht es natuerlich
\r
70 auch noch GeoHandler, also Programme, die diese Information nutzen
\r
71 koennen. Z.B. kann man Firefox so einstellen, dass er die Koordinate
\r
72 in OpenStreetMap [6] oeffnet -- oder in einem lokalen Programm, das
\r
73 diese exzellenten Kartendaten nutzt :). Auf der Shell ist das dann
\r
74 eher problematisch. Aber man kann zumindest mal die URI in eine all-
\r
75 tagstaugliche Bezeichung, wie bspw. Stadtname, umwandeln lassen. OSM
\r
76 hat dazu ein schoenes Interface und GeoClue soll das auch koennen.
\r
78 Auch der umgekehrte Weg, von einem Name oder einer (strukturierten)
\r
79 Adressangabe zu einer GeoURI ist eine Wuenschenswerte Option. Damit
\r
80 koennte man dann schnell eine Liste von GeoURIs erstellen, die den
\r
81 Startpunkt, Zwischenhalte und Endpunkt fuer eine Navigation ergeben.
\r
82 Leider gibt es auch hier nichts, was rein per CLI funktioniert.. und
\r
83 selbst die grafischen Alternativen haben noch Nachholbedarf: Auto-
\r
84 und Rad/Fussgaenger-Navigation funktioniert schon ganz prima, aber
\r
85 noch besser waere natuerlich auch den OEPNV einzubinden.. aber dazu
\r
86 muessen einige Verkehrsverbuende erstmal ihre Fahrplandaten in frei
\r
87 und nicht kaputt (tm) veroeffentlichen und mich nicht immer nur mit
\r
88 Webinterfaces abspeisen...
\r
90 Eine weiter Nutzungsmoeglichkeit: Wetterdaten. Ich habe schonmal ge-
\r
91 schrieben, wie schwer es ist gute und freie Wetterdaten zu bekommen;
\r
92 daran hat sich leider wenig geaendert. Die vom Deutschen Wetterdienst
\r
93 erstellten GAFOR-Wetterdaten sind zwar inzwischen offen im Internet
\r
94 [7] einsehbar, aber da eine (dokumentierte) API fehlt, kann sich das
\r
95 Format oder die URL jederzeit aendern. Ausserdem ist GAFOR nur fuer
\r
96 Deutschland gueltig.
\r
98 Daneben gibt es die METAR-Daten (Wetter am jeweiligen Flugplatz), TAF
\r
99 (Vorhersagen) und SIGMET (Warnungen). Die sind zwar prinzipiell frei
\r
100 verfuegbar, aber woher man sie bekommt ist immer so eine Sache. Am Ende
\r
101 landet man meist auf der Seite der amerikanischen NOAA -- [8] bzw. [9].
\r
103 Bei Wetterdaten muss man sich wohl prinzipbedingt damit abfinden, dass
\r
104 man sie nur schlecht "lokal" bereithalten kann, aber problematisch bei
\r
105 METAR ist, dass sie erstmal nur fuer Flugplaetze gelten. Gerade weil in
\r
106 Zukunft, Wetterphaenomene eher lokal statt regional sein werden, reicht
\r
107 das nicht aus. Wir brauchen also mehr oeffentlich zugaengliche Wetter-
\r
108 stationen. Zum Glueck haben sich auch hier schon einige Seiten heraus-
\r
109 gebildet, die versuchen diese ganzen Informationen zusammenzufassen. So
\r
110 gibt es u.a. die OpenWeatherMap [10] und den WeatherUnderground [11].
\r
111 Das Problem: Zumindest bei letzterem wird einem beim Durchlesen der
\r
112 AGB schnell schlecht...
\r
114 Es gibt viel zu tun.
\r
117 [0] http://freegeoip.net/
\r
118 [1] http://dev.maxmind.com/geoip/legacy/geolite/
\r
119 [2] http://dev.maxmind.com/geoip/geoip2/geolite2/
\r
120 [3] http://openbmap.org/
\r
121 [4] http://www.openwlanmap.org/
\r
122 [5] http://www.freedesktop.org/wiki/Software/GeoClue/
\r
123 [6] http://openstreetmap.org/
\r
124 [7] http://www.dwd.de/lfberichte
\r
125 [8] http://weather.noaa.gov/pub/data/observations/metar/stations/
\r
126 [9] http://weather.noaa.gov/pub/data/observations/metar/decoded/
\r
127 [10] http://openweathermap.org/
\r
128 [11] http://www.wunderground.com/
\r
projects / krt-msg / blob