1 From: Boris Kraut <krt@nurfuerspam.de>
\r
2 Date: Sat, 11 May 2013 02:15:17 +0200
\r
4 Message-ID: <20130511021517.D8f5RO@silberbruch>
\r
8 To: undisclosed-recipients: ;
\r
9 Subject: [.plan] Portables /home/, XDG und Android API
\r
10 Reply-To: Boris Kraut <krt@nurfuerspam.de>
\r
12 Ich bin bekanntlich kein grosser Fan von den XDG, den von
\r
13 freedesktop.org aufgestellten X Desktop Guidelines. Sicher,
\r
14 sie vereinheitlichen, aber manchmal steht diese Vereinheit-
\r
15 lichung eben meiner speziellen Nutzungsart entgegen, z.B.
\r
16 beim Aufbau und der Organisation des Home-Verzeichnises.
\r
18 Bisher wurden Benutzerkonfigurationsdateien einfach im Home-
\r
19 Verzeichnis des jeweiligen Nutzers abgelegt und trugen den
\r
20 Namen der Anwendung Dem Namen war ein "." vorangestellt,
\r
21 um die Datei zu verstecken und von Nutzerdaten unterscheiden
\r
22 zu koennen. Reichte eine einzelne Datei nicht aus bzw. wurden
\r
23 zusaetzlich zu den Nutzerdaten auch Anwendungsdaten angelegt,
\r
24 nutzten die meisten Programme ein komplettes Verzeichnis nach
\r
25 dem selben Namensmuster -- die Konfigurationsdatei war dann
\r
26 mit den Anwendungsdaten innerhalb dieses Ordners zu finden,
\r
27 der den Namen des jeweiligen Programms verwendete.
\r
29 XDG legt nahe, dass man Anwendungsdaten und -konfigurationen
\r
30 an sich oertlich trennen sollte und erst in zweiter Ebene
\r
31 nach Programmnamen. Dazu gibt es die beiden Umgebungsvariablen
\r
32 XDG_DATA_HOME und XDG_CONFIG_HOME -- falls nicht gesetzt
\r
33 sollen die Ordner $HOME/.local/share und $HOME/.config ver-
\r
34 wendet werden, anstatt auf das alte, oben erlaeuterte Schema
\r
35 zurueck zu fallen: Diese sollen nur noch lesend genutzt werden.
\r
37 In der XDG-Denke, haben auch andere -- besser: keine -- Daten
\r
38 etwas im Home-Verzeichnis verloren und so werden weitere
\r
39 Unterordner bestimmt. Diese werden jedoch nicht per Umgebungs-
\r
40 variable festgelegt, sondern in $XDG_CONFIG_HOME/user-dirs.dirs
\r
41 -- einer Datei die diese zusaetzlichen Variablen und Werte
\r
44 XDG_DESKTOP_DIR="$HOME/Desktop"
\r
45 XDG_DOWNLOAD_DIR="$HOME/Downloads"
\r
46 XDG_TEMPLATES_DIR="$HOME/Templates"
\r
47 XDG_PUBLICSHARE_DIR="$HOME/Public"
\r
48 XDG_DOCUMENTS_DIR="$HOME/Documents"
\r
49 XDG_MUSIC_DIR="$HOME/Music"
\r
50 XDG_PICTURES_DIR="$HOME/Pictures"
\r
51 XDG_VIDEOS_DIR="$HOME/Videos"
\r
53 Es gibt noch weitere XDG-Variablen, aber dazu spaeter mehr. Im
\r
54 Moment geht es mir um etwas anderes. Ich halte das Vorhandensein
\r
55 solcher Variablen fuer eine gute Idee. Sie beschreiben Ordner,
\r
56 die man in sehr vielen Faellen auf einem Desktop-System haben
\r
57 und nutzen koennte. Was mich jedoch stoert ist, dass XDG sehr
\r
58 viral ist: Zum einen muss ich XDG nutzen, um XDG-Anwendungen
\r
59 mitzuteilen, dass sie nicht XDG nutzen sollen. Zum anderen wird
\r
60 aktiv auf Entwickler Einfluss genommen, damit diese auch ohne dass
\r
61 XDG-Variablen gesetzt sind, die XDG-Sturktur einhalten, anlegen
\r
62 und dem "alten Weg" vorziehen. Auch schade: Man kann den Inhalt
\r
63 von "user-dirs.dirs" nicht einfach per ENV-Variable ueberschreiben.
\r
65 So sehr ich mich auch gegen XDG ausspreche, desto mehr Programme
\r
66 nutzen XDG und folgen dessen Empfehlung, es proaktiv zu erzwingen,
\r
67 indem sie "den alten Weg" nicht mehr oder nur lesend anbieten. Es
\r
68 wird klar, dass ich fuer ein portableres Home-Verzeichnis zumindest
\r
69 optional XDG beachten muss, deshalb habe ich mir Gedanken ueber
\r
70 meine Verzeichnisstruktur gemacht. Im Vergleich zur letzten Be-
\r
71 sprechung meines Homeverzeichnis bei ioexception.de, hat sich doch
\r
72 einiges geaendert. Statt mit "Desktop" und "Downloads" Ordnern zu
\r
73 leben, die diverse Anwendungen immer und immer wieder erstellen,
\r
74 habe ich diesen -- in meinem Schema -- sinnvolle Namen gegeben.
\r
75 Ausserdem wurde mein Ordner fuer Vortraege und Praesentationen
\r
76 zum generellen Speicherort fuer Dokumente.. oder besser fuer
\r
77 "dokumentierte Ereignisse".
\r
80 XDG_CONFIG_HOME=$HOME
\r
82 XDG_RUNTIME_DIR=/run/krt
\r
85 XDG_DESKTOP_DIR="$HOME"
\r
86 XDG_DOWNLOAD_DIR="$HOME/tmp"
\r
87 XDG_TEMPLATES_DIR="$HOME"
\r
88 XDG_PUBLICSHARE_DIR="$HOME/pub"
\r
89 XDG_DOCUMENTS_DIR="$HOME/doc"
\r
90 XDG_MUSIC_DIR="$HOME/pls"
\r
91 XDG_PICTURES_DIR="$HOME/pic"
\r
92 XDG_VIDEOS_DIR="$HOME/mov"
\r
94 Daneben gibt es noch die Ordner src, bin, man und mail, deren Sinn
\r
95 wohl offensichtlich ist. Zudem gibt es weiterhin misc, der in
\r
96 vielerlei Hinsicht die selben Aufgaben erfuellt hat, wie doc jetzt,
\r
97 aber derzeit noch einem anderen Ordnungsparadigma folgt. Frueher
\r
98 oder spaeter wird misc nicht mehr benoetigt werden.
\r
100 Damit sollte dann ja alles gut sein, oder? Nicht ganz, denn wer
\r
101 hier einige Zeit mitliest, weiss, dass ich mich auch mit dem
\r
102 Nicht-so-ganz-Linux namens Android beschaeftige. Android kennt
\r
103 prinzipiell eine aehnliche Verzeichnisstruktur, legt diese
\r
104 aber nicht im Home-Verzeichnis -- das waere /data bzw. die
\r
105 jeweilige Multi-User-Version davon -- ab, sondern nutzt dafuer
\r
106 /sdcard -- auch hier: oder die jeweilige MultiUser-Version --,
\r
107 was wenig mit der SD-Karte zu tun hat, sondern generell als
\r
108 Name fuer nutzerspezifischen Speicher verwendet wird.
\r
110 Ebenfalls nutzt Android hier keine veraenderbaren Umgebungs-
\r
111 variablen, sondern festkodierte Werte, die ueber die API [1]
\r
112 via getExternalFilesDir(NAME) abrufbar sind. NAME folgt dabei
\r
113 einem relativ simplen Schema, z.B. DIRECTORY_MUSIC oder
\r
114 DIRECTORY_RINGTONES. Die Standardverzeichnisse sind:
\r
117 > Media scanner classifies all media found here as user music.
\r
120 > Media scanner classifies all media found here as a podcast.
\r
123 > Media scanner classifies all media found here as a ringtone.
\r
126 > Media scanner classifies all media found here as an alarm
\r
130 > Media scanner classifies all media found here as a notification
\r
134 > All photos (excluding those taken with the camera).
\r
137 > All movies (excluding those taken with the camcorder).
\r
140 > Miscellaneous downloads.
\r
142 Die einzige Option, dieses Verhalten zu beeinflussen, wird wohl
\r
143 eine massiver Einsatz von Symlinks sein; nicht unbedingt die
\r
144 ideale Loesung. Es wird immer ersichtlicher, dass -- so sehr mir
\r
145 Android an der Oberflaeche gefaellt -- es nicht das ist, womit
\r
146 ich gluecklich werde. Ich kann nur hoffen, dass es bald gut
\r
147 nutzbare unixartigere Systeme fuer die ansonsten ganz gefaellige
\r
151 [0] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
\r
152 [1] https://developer.android.com/guide/topics/data/data-storage.html#AccessingExtFiles
\r
153 [2] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
\r
154 [3] https://en.wikipedia.org/wiki/Unix_directory_structure
\r
projects / krt-msg / blob