J'ai dû installer OsmAnd sur un téléphone sans connexion internet disponible depuis le-dit téléphone.

L'installation de l'application en soit n'a pas posé de problème, l'installation des cartes présente quelques subtilités.

J'ai :

• Téléchargé les cartes depuis http://download.osmand.net/rawindexes/
• Dézippé et fusionné les fichiers dans un répertoire
• Transféré les fichiers dans /sdcard/Android/data/net.osmand.plus/files
• Fermé complètement et relancé Osmand

Je me suis aidé des informations données ici : http://osmand.net/help/HowToArticles.html

Je suis actuellement un tutoriel Python à partir de mon PC Windows mais je code sur un PC linux en SSH avec Putty.

Le souci c'est que j'utilise un thème avec des couleurs particulières et le shell donne un rendu dégueulasse dans Putty, certaines parties de mon prompt ne sont carrément pas lisibles.
J'ai donc configuré ma session Putty pour qu'elle utilise les mêmes couleurs que mon environnement Cinnamon (je suis sur Mint 18).

1. Installer un sélecteur/convertisseur de couleurs (le premier que j'ai trouvé dans le Software Manager : gcolor2).
2. Ouvrir les préférences du terminal (Edit > Profile preferences)
3. Dans l'onglet couleurs cliquer sur chacune des couleurs de la palette et noter son code hexadécimal, elles correspondent de gauche à droite au noir, rouge, vert, jaune, bleu, magenta, cyan et blanc avec la variante bold en dessous utilisée pour afficher des éléments en gras.
4. Convertir chaque code hexadécimal en RVB
5. Aller dans les propriétés de la session sauvegardée dans Putty, Window > Colours
6. Donner respectivement la couleur convertie RVB du blanc/blanc gras/noir/noir gras à Default Foreground/Default Bold Foreground/Default Background/Default bold Background
7. Donner à chaque couleur ANSI son équivalent converti en RVB.
8. Sauvegarder le profil

Pour moi ça donne :

• Noir : Hexa 2E3436/RVB 46 52 54
• Noir bold : 555753 / 85 87 83
• Rouge : CC0000 / 204 0 0
• Rouge bold : EF2929 / 239 41 41
• Vert : 4E9A06 / 78 154 6
• Vert bold : 8AE234 / 138 226 52
• Jaune : C4A000 / 196 160 0
• Jaune bold : FCE94F / 252 233 79
• Bleu : 3465A4 / 52 101 164
• Bleu bold : 729FCF / 114 159 207
• Magenta : 75507B / 117 80 123
• Magenta bold : AD7FA8 / 173 127 168
• Cyan : 06989A / 6 152 154
• Cyan bold : 34E2E2 / 52 226 226
• Blanc : D3D7CF / 211 215 207
• Blanc bold : EEEEEC / 238 238 236

J'ai eu un petit souci lors de l'installation de ma VM LM18 dans Virtualbox sous Windows je fais un petit récapitulatif ici.

Après l'installation j'ai dû :

• Faire un apt upgrade
• Installer les pilotes propriétaires (:s)
• Installer le paquet virtualbox-guest-additions-iso des dépôts
• M'assurer que l'accélération 3D est activée dans les paramètres de la VM

Jusque-là rien d'anormal, c'est exactement ce que j'avais fait avec LM17 sauf que j'avais un message qui apparaissait à chaque ouverture de session "Cinnamon is running in software-rendering mode" m'avertissant que la VM risquait de consommer beaucoup plus de ressources que prévu.

Pour corriger le problème j'ai du installer les guest additions à partir de l'ISO fournie par Virtualbox. Après vérification la version des dépôts était la 5.0.24 et celle de l'ISO la 5.0.26.

J'en profiterai pour ajouter ma check-list post-installation de LM18 un peu plus tard.

BONUS:
Tant que j'y suis, si jamais pour une raison ou une autre on définit explicitement la résolution, le redimensionnement automatique ne fonctionne plus, pour le réactiver il faut supprimer le fichier ~/.monitors.xml

Pour détailler la config après avoir jeté un oeil à la note référençant la page d'aide d'Ubuntu :

Je me retrouve avec :

• /etc/auto.master.d/serveur.autofs

  /mnt/<serveur> /etc/auto.master.d/auto.<serveur>

• /etc/auto.master.d/auto.serveur

  <Nom_repertoire_montage1> -fstype=nfs <ip_serveur>:</chemin/vers/partage/NFS1>
  <Nom_repertoire_montage2> -fstype=nfs <ip_serveur>:</chemin/vers/partage/NFS2>
  ...

Vérification avec un simple :

ll /mnt/<serveur>/<Nom_repertoire_montage1>

L'intérêt est ici de monter un partage (dans mon cas NFS) à la demande (uniquement lorsqu'un processus tente d'y accéder) et de le démonter après une certaine période d'inactivité. Dans l'exemple ci-dessus il s'agit d'un montage indirect, c'est à dire que le point de montage final n'existe pas tant que le partage n'est pas monté, ce qui peut poser problème pour certains usages. Dans ce cas il vaut mieux utiliser des montages directs :

• /etc/auto.master.d/serveur.autofs

  /- /etc/auto.master.d/autofs.<serveur>

• /etc/auto.master.d/auto.serveur

  /mnt/<serveur>/<Nom_repertoire_montage1> -fstype=nfs <ip_serveur>:</chemin/vers/partage/NFS1>
  /mnt/<serveur>/<Nom_repertoire_montage2> -fstype=nfs <ip_serveur>:</chemin/vers/partage/NFS2>
  ...

On voit ici que le point de montage racine n'est pas spécifié dans le fichier serveur.autofs car pour chaque partage il est explicitement défini dans le fichier auto.serveur