Il suffit de modifier le fichier /etc/xdg/lxsession/LXDF-pi/autostart en ajoutant la ligne de commande que l'on souhaite lancer.
Si la ligne est précédée de @, les erreurs dues à la commande correspondante seront ignorées et le script passera à la commande suivante.

C'est quoi l'intérêt ? Pourquoi vouloir partager sa position GPS en temps réel ?
Personnellement, je ne vois pas pourquoi j'irai dire "coucou, je suis là" (ou j'étais là).
Je veux bien que quelqu'un éclaire ma lanterne sur ce sujet, car je ne comprends pas bien le but de la manœuvre.

Edit : SebSauvage m'a donné l'exemple de deux personnes qui ne se connaissent pas dans la vraie vie et qui ont rendez-vous (ils se sont connus sur les internets). Ils pourraient utiliser une page de ce type pour se retrouver plus facilement, en évitant de se croiser plusieurs fois sans se voir.

Petit script pour désactiver l'écran de veille (quand je regarde des vidéos sur internet par exemple)

#!/bin/bash
ssav=`ps -ausev | grep xautolock | wc -l`
if [ $ssav != "0" ]
then
xset s off -dpms
xautolock -exit
notify-send --icon=/usr/share/icons/gnome/256x256/status/dialog-warning.png "Économiseur d'écran désactivé"
else
xset s on +dpms
xautolock -time 10 -locker 'i3lock -dti ~/.config/openbox/LockScreen02.png' &
notify-send --icon=/usr/share/icons/gnome/256x256/status/dialog-information.png "Économiseur d'écran activé"
fi

À adapter à l'économiseur d'écran utilisé.

Tout est dans le titre.

Edit : pour supprimer la mise en veille au bout de 10 minutes d'inactivité :

Ouvrir le fichier lightdm.conf

sudo nano /etc/lightdm/lightdm.conf

Chercher la section [SeatDefaults] et repérer la ligne

#xserver-command=X

Enlever le # qui se trouve en début de ligne pour activer l’envoi de commandes au serveur X et modifier la ligne comme suit :

xserver-command=X -s 0 -dpms

DPMS c’est Display Power Management Signaling = Gestion de l’alimentation du moniteur vidéo. Il faut lui dire qu’on ne veut pas de délai avant extinction du moniteur en cas d’inactivité du serveur X. C’est le rôle du -s 0, le 0 signifiant qu’on désactive la mise en veille du moniteur.

Astuce trouvée sur Framboise 3.14 : https://www.framboise314.fr/14-trucs-a-connaitre-pour-personnaliser-raspbian-pixel/#Truc_6_8211_Je_veux_changer_le_fond_d8217ecran_du_bureau_de_PIXEL

C'est bôôôôô !

Comme ça va gueuler, on interdit tout rassemblement sous prétexte sanitaire. Pratique. Encore une fois, la liberté est muselée au nom de la sécurité... Si ça continue comme ça, ça va pas durer, comme dirait Jean-Claude.

This guide describes how to get an Apple Remote (A1294 silver model) to work in OSMC version 2018.08-2 (Kodi 17.6) for Raspberry Pi 3 model B+.

I bought a very cheap TSOP4838 IR receiver on eBay.
The IR receiver pins are (bulge facing you, pins down, from left): 1 - OUT, 2 - GND and 3 - Vs
The Raspberry Pi pins I used are: 01 - 3.3V, 06 - GND and 12 - GPIO18
Connect IR receiver pin 1 to RPi pin 12
Connect IR receiver pin 2 to RPi pin 06
Connect IR receiver pin 3 to RPi pin 01

Now edit the /boot/config.txt to enable and configure lirc (Linux Infrared Remote Control) :

$ cd /boot
$ sudo nano config.txt

Add as last line:

dtoverlay=lirc-rpi,gpio_in_pin=18

I think that can be simplified to dtoverlay=lirc-rpi as it seems that lirc_rpi auto-detects the IR receiver on GPIO18.

Activate the apple silver configuration:

$ cd /etc/lirc/
$ sudo rm lircd.conf
$ sudo ln -s apple-silver-A1294-lircd.conf lircd.conf

Now reboot

$ sudo reboot

The Apple Remote should now work with OSMC!

The steps below are not necessary, but could help you verify that everything works:

$ dmesg | grep lirc
[    4.289234] lirc_dev: IR Remote Control driver registered, major 244
[    4.345142] lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
[    5.411573] lirc_rpi: auto-detected active low receiver on GPIO pin 18
[    5.411759] lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at minor = 0
[    5.411763] lirc_rpi: driver registered!
[    5.666436] input: lircd as /devices/virtual/input/input0

$ sudo lsmod | grep lirc_rpi
lirc_rpi               16384  2
lirc_dev               20480  1 lirc_rpi

$ sudo ls -l /dev/lirc*
crw-rw---- 1 root video 244, 0 Nov  9 17:14 /dev/lirc0

$ sudo systemctl status lircd_helper@lirc0
* lircd_helper@lirc0.service - lircd remote support
   Loaded: loaded (/lib/systemd/system/lircd_helper@.service; static; vendor preset: enabled)
   Active: active (running) since Fri 2018-11-09 18:43:34 CET; 9min ago
  Process: 352 ExecStart=/bin/sh -c /var/run/lirc/lircd-lirc0.sh (code=exited, status=0/SUCCESS)
 Main PID: 364 (lircd)
   CGroup: /system.slice/system-lircd_helper.slice/lircd_helper@lirc0.service
           `-364 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --uinput --output=/var/run/lirc/lircd-lirc0 --pidfile=/var/run/lirc/lircd-lirc0.pid /etc/lirc/lircd.conf

$ irw
cf 0 KEY_PLAY linux-input-layer
cf 0 KEY_PLAY_UP linux-input-layer
1 0 KEY_ESC linux-input-layer
1 1 KEY_ESC linux-input-layer
1 0 KEY_ESC_UP linux-input-layer
160 0 KEY_OK linux-input-layer
160 0 KEY_OK_UP linux-input-layer

Regards
Mogens Beltoft

Pour s'en prémunir, l'ANSSI estime qu'il faudra "dégager suffisamment de ressources, dans des budgets globalement insuffisants, pour atteindre un juste niveau de sécurité."

L'ironie de cette phrase fait froid dans le dos. Globalement, ça veut dire : "vous n'avez aucun moyen pour fonctionner normalement mais il va falloir que vous trouviez de quoi vous défendre quand même".

C'est un peu comme le sketch des inconnus :

• On a faim !
• Bein, mangez !
• Oui mais on n'y arrive pas !
• Bein, il faut vous forcer !