TuxMake et TuxRun étant globalement des wrapper autour d'outils déjà existant (make, qemu, fvp, LAVA, …) utiliser python permet de développer assez rapidement et fournis beaucoup de fonctions pour écrire un wrapper (subprocess par exemple).
Oui TuxMake est utilisé par de plus en plus de mainteneurs du noyau principalement du fait que les rapports de bugs qui sont remontés par Linaro sont basés sur TuxMake.
L'adoption est lente car les développeurs on chacun des scripts maison qui correspondent à leur cas d'usage. Ce n'est donc pas forcément pertinent de changer tant que le cas d'usage n'évolue pas. Les bugs un peu difficile à reproduire (du fait de la toolchain principalement) sont souvent une bonne occasion de tester TuxMake.
TuxRun étant un outils beaucoup plus récent, l'adoption est beaucoup plus faible même si nous savons que quelques mainteneurs l'utilise déjà. L'adoption de TuxRun devrait probablement suivre la même courbe que celle de TuxMake mais avec un certain décalage.
Il est aussi difficile de savoir qui utilise TuxMake/TuxRun car les mainteneurs mentionne rarement publiquement (du fait de la publicité qui en découle) les outils qu'ils utilisent.
C'est malheureusement la première réaction que l'on a des développeurs du noyaux lorsque l'on présente TuxMake : "c'est trivial de compiler le noyaux". On parle alors de cross-compilation ou de reproduire une erreur de compilation et d'un coup c'est moins trivial même pour eux !
Après il est vrai que compiler un noyaux pour la machine host qui compile en changeant quelques options dans le menuconfig c'est relativement facile. Mais en dehors de ce cas très simple ça devient vite bien plus hardu.
Bonjour et merci pour ces retours sur la problématique initiale.
Quelques remarques en tant qu'auteur de KissCache :
cache HTTPS
La solution proposée implique la réécriture des URL de toutes les ressources demandées. Elle est donc beaucoup plus intrusive et non standard que l'utilisation d'un proxy classique.
[…]
Et il faut donc disposer d'outils spécialement écrits pour être compatibles avec kisscache.
Effectivement c'est un inconvénient de devoir adapter les outils pour qu'ils utilisent KissCache. C'est cependant très rapide à faire puisqu'il suffit de préfixer les urls. Dans l'outil de CI que nous utilisons (LAVA), le support de KissCache représente moins de 10 lignes de code.
L'alternative étant de faire du MITM avec la création d'un certificat racine et de le déployer sur tous les clients ce qui me semble très lourd et limite au niveau sécurité.
KISS
Clairement la gestion d'un cache HTTP(S) n'est pas simple. Le protocole HTTP est compliqué
Le nom de KissCache a pour but de bien indiquer que le fonctionnement de KissCache est simple, voir stupide et qu'il ne prends pas en compte toutes les subtilités du protocole.
nginx
La directive "proxy_cache_lock" permet de n'avoir qu'un client à la fois en train de télécharger une ressource.
D'après la documentation les autres clients vont devoir attendre que la ressource soit entièrement téléchargée avant de pouvoir y accéder.
Si nginx met plusieurs minutes à télécharger la ressource, alors les autres clients vont attendre plusieurs minutes avant de recevoir ne serait-ce que les premier bit de donnée.
KissCache permet à tous les clients, en simultané, de recevoir le fichier en même temps au fur et à mesure de son téléchargement par KissCache. Il n'y a donc qu'une très faible latence (le temps pour le worker celery de démarrer la tache).
De plus nginx ne permet toujours pas de mettre en cache les ressource disponible via https.
Async python
L'implémentation proposée souffre d'une même problème que nginx : les clients vont attendre le téléchargement complet de la ressource avant de recevoir une réponse. Le cache induit donc une latence importante lors du premier téléchargement.
Sinon j'aime bien l'idée de se baser sur async. J'y avais pensé mais je voulais aussi avoir une interface web pour voir l'état du cache, ainsi qu'une interface d'admin permettant de supprimer les urls mises en cache en cas de problème.
Travaillant tous les jours avec Django depuis de nombreuses année, j'ai donc choisi Django.
Dans le cas de Squid, tant que l'url n'aura pas été mise en cache, toute requête forcera un second téléchargement.
Avec KissCache, la première requête déclenche le téléchargement, toute requête suivante ne fera que streamer le fichier au client, y compris durant le téléchargement par la tache Celery.
Ce fonctionnement permet de fortement diminuer l'utilisation réseau. Chose que squid ne peux malheureusement pas faire.
Lorsqu'une requête arrive, KissCache va vérifier si l'url est déjà en cache (via la db).
Si la ressource existe déjà dans la DB (qui garantie donc l'unicité des ressources), django stream la ressource au client
Si la ressource n'existe pas, django démarre une tache Celery et stream la ressource au client (même code que dans le premier cas).
Le fait d'utiliser Celery permet de ne télécharger chaque url qu'une unique fois. De plus, si le client ferme la connexion, l'url continuera d'être téléchargée par la tache Celery.
Clairement, cela ne peut pas être utilisé pour surfer le web car l'utilisateur ne va pas réécrire toutes les URL.
Exactement c'est pour le système de CI.
D'autre part, le changement de domaine brise un certain nombre de mécanisme sécurités.
Oui et non car KissCache va :
1/ valider les certificats SSL
2/ le client s’adresse explicitement à l'instance KissCache donc fait explicitement confiance à cette instance.
Pour faire la même chose avec un proxy, il faut :
1/ créer un certificat racine
2/ l'installer sur chaque client
3/ forger des certificats pour chaque domaine demandé
Le client fait donc entièrement confiance au proxy qui va forger des certificats pour linuxfr.org par exemple.
Ceci brise l'intégralité des mécanismes de sécurité car le client doit fait entièrement confiance au certificat racine du proxy. Un attaquant qui prend le contrôle du proxy peut alors mettre en place un MitM sans aucun problème avec l'intégralité des domaines.
Qu'est-ce que "au même moment" ? Cela ne me paraît pas se produire souvent…
Dans un système de validation où plusieurs job sont lancé en parallèle avec les même artefacts cela arrive absolument tout les jours.
Dans notre cas, LKFT va valider chaque RC du noyaux linux sur 6 types de machines en lançant pour chaque type une dizaine de job différent. Sachant que nous avons au minimum 4 machine de chaque type, LAVA va nécessairement faire tourner des jobs en parallèle et donc utiliser les même artefacts au même moment.
Et je suis épaté par le fait que Squid fasse plusieurs requêtes en cas de demandes simultanées. D'un autre côté en y réfléchissant, tant qu'il n'a pas reçu de réponse pour une ressource, il ne peut pas regarder dans les en-têtes si elle peut être gardée en cache.
Exactement, KissCache est pensé pour ne faire qu'une seule requête et cela demande un peu de gymnastique. Donc c'est assez logique que squid ne le fasse pas (squid faisant énormément de chose que KissCache ne fera jamais).
En proxy-cache qui marche bien, j'entends souvent parler de Varnish (pas essayé).
Malheureusement toujours la même réponse : Varnish étant un proxy, il ne supporte pas le https
J'aurai largement préféré utiliser un logiciel existant plutôt que de devoir en développer un nouveau. Malheureusement je n'ai rien trouvé.
Je suis tout à fait d'accord sur le fait que l'on peux faire beaucoup mieux et que de nombreuses choses peuvent-être améliorés dans KissCache.
Mais le but est d'avoir un logiciel simple et qui correspond au cas d'usage, d'où son nom.
Dans le cas d'un système de CI, les ressources sont construites (par Gitlab ou Jenkins), mise à disposition via un serveur https (S3, nginx, …) puis testé par LAVA.
Les urls étant unique pour chaque version testé, il n'est pas utile de vérifier que les ressources distantes changent.
Suite à une demande d'un utilisateur, je suis en train de voir pour ajouter l'éviction du cache.
Prends aussi en compte que c'est environ une semaine de boulot, pas plus.
apt-cacher-ng étant un proxy transparent il n'est pas possible de mettre en cache des ressources disponible via https.
En fait c'est possible mais il faut installer un certificat racine sur chaque client et générer des certificats signés avec ce certificat racine pour chaque domaine. Il faut donc créer de faux certificats SSL!
Sachant que certains client peuvent se rendre compte de cette manipulation et fermer la connexion.
Le fait de préfixer l'url avec celle de l'instance de KissCache permet de mettre en cache des url https. En effet, le client se connecte à KissCache qui retourne son propre certificat (valide) et les données en cache. De son côté KissCache se connecte en https au site demandé et valide lui même le certificat.
Il faut donc avoir confiance en l'instance KissCache mais moins que dans le cas où il faut installer un certificat racine maison.
Je n'ai surtout pas assez confiance dans ce service pour envoyer les numéro de téléphone des utilisateurs de R.A.S. dedans. Je préfère l'API de Free Mobile.
R.A.S. est complètement agnostique vis à vis de l'activité que tu veux pratiquer. La seule chose que demande R.A.S. c'est :
un début
une fin
une date d'alerte
une description
un point géographique intéressant pour cette sortie
Le champs description étant un simple champ textuel, à toi de mettre ce que tu veux dedans.
Si tu as besoin d'ajouter des info spécifique et que la description n'est pas suffisante, fait un bug report et je verrai comment intégrer cela.
J'ai vaguement cherché mais je n'ai pas trouvé grand chose qui fonctionne vraiment. Si quelqu'un a l'information, je suis preneur pour l'intégrer dans SMSForward.
Sans rigoler ça pourrait être une option activée uniquement si l'utilisateur le souhaite.
Je pensait permettre aussi d'uploader régulièrement la position GPS depuis le téléphone vers l'application. La trace serait alors visible pour les amis de la personne si et seulement si celle-ci est en retard (et qu'elle a activé la fonction dans l'application Android).
Je pensais aussi supprimer automatiquement les données GPS dés que la personne indique être rentrée.
Merci pour le liens. Je vais voir ce que je peux faire sachant que j'ai choisie la liste de cipher assurant une bonne compatibilité avec les navigateurs et OS existants. Je peux faire mieux en supportant moins de navigateurs.
Tu as aussi raison pour le HSTS : je vais le rajouter.
L'instance randoamissecours.org est-elle un vrai service ou faut-il vraiment privilégier de l'héberger ailleurs ?
L'instance qui tourne sur randoamissecours.org est faites pour être utilisée directement par les personnes intéressées.
Le site est hébergé sur un serveur chez OVH qui tourne sans problème notable depuis quelques années. J'ai donc plutôt confiance dans la fiabilité de ce serveur.
Si tu souhaite installer R.A.S. sur ton serveur c'est assez facile si tu as déjà configurer Apache pour servir du python.
Sinon AMHA ce qui est primordial sur l'appli android c'est de pouvoir déclarer la fin d'une sortie.
Je suis bien d'accord avec toi. Je serai d'ailleurs le premier utilisateur de cette fonctionnalité. N'étant malheureusement pas très fort en développement d'applications Android, je n'ai pas encore trouvé le temps de développer cette fonctionnalité. Si quelqu'un sait faire je suis preneur !
[^] # Re: Ouahhh
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche TuxRun et le noyau Linux. Évalué à 3 (+2/-0).
TuxMake et TuxRun étant globalement des wrapper autour d'outils déjà existant (make, qemu, fvp, LAVA, …) utiliser python permet de développer assez rapidement et fournis beaucoup de fonctions pour écrire un wrapper (subprocess par exemple).
[^] # Re: Ouahhh
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche TuxRun et le noyau Linux. Évalué à 2 (+1/-0).
Oui TuxMake est utilisé par de plus en plus de mainteneurs du noyau principalement du fait que les rapports de bugs qui sont remontés par Linaro sont basés sur TuxMake.
L'adoption est lente car les développeurs on chacun des scripts maison qui correspondent à leur cas d'usage. Ce n'est donc pas forcément pertinent de changer tant que le cas d'usage n'évolue pas. Les bugs un peu difficile à reproduire (du fait de la toolchain principalement) sont souvent une bonne occasion de tester TuxMake.
TuxRun étant un outils beaucoup plus récent, l'adoption est beaucoup plus faible même si nous savons que quelques mainteneurs l'utilise déjà. L'adoption de TuxRun devrait probablement suivre la même courbe que celle de TuxMake mais avec un certain décalage.
Il est aussi difficile de savoir qui utilise TuxMake/TuxRun car les mainteneurs mentionne rarement publiquement (du fait de la publicité qui en découle) les outils qu'ils utilisent.
[^] # Re: Trivial ?!?!?!
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche TuxMake et le noyau Linux. Évalué à 4.
C'est malheureusement la première réaction que l'on a des développeurs du noyaux lorsque l'on présente TuxMake : "c'est trivial de compiler le noyaux". On parle alors de cross-compilation ou de reproduire une erreur de compilation et d'un coup c'est moins trivial même pour eux !
Après il est vrai que compiler un noyaux pour la machine host qui compile en changeant quelques options dans le menuconfig c'est relativement facile. Mais en dehors de ce cas très simple ça devient vite bien plus hardu.
[^] # Re: incomplet
Posté par Rémi Duraffort (site web personnel) . En réponse au message Offre d'emploi chez Linaro. Évalué à 1.
Je peux mais ça dépends de chaque pays du monde.
[^] # Re: Outils intéressants
Posté par Rémi Duraffort (site web personnel) . En réponse au message Offre d'emploi chez Linaro. Évalué à 3.
Il faut vraiment que j'écrive des articles pour présenter tuxmake, tuxrun et leur pendant dans le cloud tuxbuild and tuxtest.
[^] # Re: Fugaku ?
Posté par Rémi Duraffort (site web personnel) . En réponse au message Offre d'emploi chez Linaro. Évalué à 3.
C'est entre autre effectivement le cas.
Linaro est aussi dans le top 10 des contributeurs du noyaux : Some 5.16 kernel development statistics
[^] # Re: incomplet
Posté par Rémi Duraffort (site web personnel) . En réponse au message Offre d'emploi chez Linaro. Évalué à 1.
Merci, j'ai rajouté le full-remote.
Je n'ai par contre pas la fourchette de salaire. Je sais que c'est abordé lors du premier interview avec le RH.
# Retour d'expérience
Posté par Rémi Duraffort (site web personnel) . En réponse au journal KissCache, kiss qui se cache. Évalué à 3.
Bonjour et merci pour ces retours sur la problématique initiale.
Quelques remarques en tant qu'auteur de KissCache :
Effectivement c'est un inconvénient de devoir adapter les outils pour qu'ils utilisent KissCache. C'est cependant très rapide à faire puisqu'il suffit de préfixer les urls. Dans l'outil de CI que nous utilisons (LAVA), le support de KissCache représente moins de 10 lignes de code.
L'alternative étant de faire du MITM avec la création d'un certificat racine et de le déployer sur tous les clients ce qui me semble très lourd et limite au niveau sécurité.
Le nom de KissCache a pour but de bien indiquer que le fonctionnement de KissCache est simple, voir stupide et qu'il ne prends pas en compte toutes les subtilités du protocole.
D'après la documentation les autres clients vont devoir attendre que la ressource soit entièrement téléchargée avant de pouvoir y accéder.
Si nginx met plusieurs minutes à télécharger la ressource, alors les autres clients vont attendre plusieurs minutes avant de recevoir ne serait-ce que les premier bit de donnée.
KissCache permet à tous les clients, en simultané, de recevoir le fichier en même temps au fur et à mesure de son téléchargement par KissCache. Il n'y a donc qu'une très faible latence (le temps pour le worker celery de démarrer la tache).
De plus nginx ne permet toujours pas de mettre en cache les ressource disponible via https.
L'implémentation proposée souffre d'une même problème que nginx : les clients vont attendre le téléchargement complet de la ressource avant de recevoir une réponse. Le cache induit donc une latence importante lors du premier téléchargement.
Sinon j'aime bien l'idée de se baser sur async. J'y avais pensé mais je voulais aussi avoir une interface web pour voir l'état du cache, ainsi qu'une interface d'admin permettant de supprimer les urls mises en cache en cas de problème.
Travaillant tous les jours avec Django depuis de nombreuses année, j'ai donc choisi Django.
[^] # Re: usage ?
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche KissCache un service de mise en cache KISS. Évalué à 2.
Dans le cas de Squid, tant que l'url n'aura pas été mise en cache, toute requête forcera un second téléchargement.
Avec KissCache, la première requête déclenche le téléchargement, toute requête suivante ne fera que streamer le fichier au client, y compris durant le téléchargement par la tache Celery.
Ce fonctionnement permet de fortement diminuer l'utilisation réseau. Chose que squid ne peux malheureusement pas faire.
[^] # Re: vraiment ?
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche KissCache un service de mise en cache KISS. Évalué à 1.
Lorsqu'une requête arrive, KissCache va vérifier si l'url est déjà en cache (via la db).
Si la ressource existe déjà dans la DB (qui garantie donc l'unicité des ressources), django stream la ressource au client
Si la ressource n'existe pas, django démarre une tache Celery et stream la ressource au client (même code que dans le premier cas).
Le fait d'utiliser Celery permet de ne télécharger chaque url qu'une unique fois. De plus, si le client ferme la connexion, l'url continuera d'être téléchargée par la tache Celery.
[^] # Re: usage ?
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche KissCache un service de mise en cache KISS. Évalué à 2.
Il faut aussi connaître la liste des domaines qui va falloir mettre en cache pour les inclure dans le Root CA.
[^] # Re: vraiment ?
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche KissCache un service de mise en cache KISS. Évalué à 4.
Moins de 500 lignes de code à maintenir.
[^] # Re: usage ?
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche KissCache un service de mise en cache KISS. Évalué à 3.
voir "Cas d’usage" dans l'article.
Exactement c'est pour le système de CI.
Oui et non car KissCache va :
1/ valider les certificats SSL
2/ le client s’adresse explicitement à l'instance KissCache donc fait explicitement confiance à cette instance.
Pour faire la même chose avec un proxy, il faut :
1/ créer un certificat racine
2/ l'installer sur chaque client
3/ forger des certificats pour chaque domaine demandé
Le client fait donc entièrement confiance au proxy qui va forger des certificats pour linuxfr.org par exemple.
Ceci brise l'intégralité des mécanismes de sécurité car le client doit fait entièrement confiance au certificat racine du proxy. Un attaquant qui prend le contrôle du proxy peut alors mettre en place un MitM sans aucun problème avec l'intégralité des domaines.
Dans notre cas, LKFT va valider chaque RC du noyaux linux sur 6 types de machines en lançant pour chaque type une dizaine de job différent. Sachant que nous avons au minimum 4 machine de chaque type, LAVA va nécessairement faire tourner des jobs en parallèle et donc utiliser les même artefacts au même moment.
[^] # Re: Autre serveur http
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche KissCache un service de mise en cache KISS. Évalué à 1.
Quand varnish est configuré en reverse proxy, un seul serveur pourra être mettre en cache (le backend).
[^] # Re: Autre serveur http
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche KissCache un service de mise en cache KISS. Évalué à 4.
Exactement, KissCache est pensé pour ne faire qu'une seule requête et cela demande un peu de gymnastique. Donc c'est assez logique que squid ne le fasse pas (squid faisant énormément de chose que KissCache ne fera jamais).
Malheureusement toujours la même réponse : Varnish étant un proxy, il ne supporte pas le https
J'aurai largement préféré utiliser un logiciel existant plutôt que de devoir en développer un nouveau. Malheureusement je n'ai rien trouvé.
[^] # Re: Invalidation ?
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche KissCache un service de mise en cache KISS. Évalué à 5.
Je suis tout à fait d'accord sur le fait que l'on peux faire beaucoup mieux et que de nombreuses choses peuvent-être améliorés dans KissCache.
Mais le but est d'avoir un logiciel simple et qui correspond au cas d'usage, d'où son nom.
Dans le cas d'un système de CI, les ressources sont construites (par Gitlab ou Jenkins), mise à disposition via un serveur https (S3, nginx, …) puis testé par LAVA.
Les urls étant unique pour chaque version testé, il n'est pas utile de vérifier que les ressources distantes changent.
Suite à une demande d'un utilisateur, je suis en train de voir pour ajouter l'éviction du cache.
Prends aussi en compte que c'est environ une semaine de boulot, pas plus.
[^] # Re: Bayard presse
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche KissCache un service de mise en cache KISS. Évalué à 3.
Je n'avais même pas fait le lien :D
[^] # Re: Autre serveur http
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche KissCache un service de mise en cache KISS. Évalué à 4.
apt-cacher-ng étant un proxy transparent il n'est pas possible de mettre en cache des ressources disponible via https.
En fait c'est possible mais il faut installer un certificat racine sur chaque client et générer des certificats signés avec ce certificat racine pour chaque domaine. Il faut donc créer de faux certificats SSL!
Sachant que certains client peuvent se rendre compte de cette manipulation et fermer la connexion.
Le fait de préfixer l'url avec celle de l'instance de KissCache permet de mettre en cache des url https. En effet, le client se connecte à KissCache qui retourne son propre certificat (valide) et les données en cache. De son côté KissCache se connecte en https au site demandé et valide lui même le certificat.
Il faut donc avoir confiance en l'instance KissCache mais moins que dans le cas où il faut installer un certificat racine maison.
[^] # Re: SMSForward et autres opérateurs de téléphonie mobile
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche Sortie de R.A.S. v0.5, alias RandoAmisSecours. Évalué à 3.
Je n'ai surtout pas assez confiance dans ce service pour envoyer les numéro de téléphone des utilisateurs de R.A.S. dedans. Je préfère l'API de Free Mobile.
[^] # Re: Pas que les randos, et les sorties bateaux?
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche Sortie de R.A.S. v0.5, alias RandoAmisSecours. Évalué à 5.
Bonjour,
R.A.S. est complètement agnostique vis à vis de l'activité que tu veux pratiquer. La seule chose que demande R.A.S. c'est :
Le champs description étant un simple champ textuel, à toi de mettre ce que tu veux dedans.
Si tu as besoin d'ajouter des info spécifique et que la description n'est pas suffisante, fait un bug report et je verrai comment intégrer cela.
[^] # Re: SMSForward et autres opérateurs de téléphonie mobile
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche Sortie de R.A.S. v0.5, alias RandoAmisSecours. Évalué à 2.
J'ai vaguement cherché mais je n'ai pas trouvé grand chose qui fonctionne vraiment. Si quelqu'un a l'information, je suis preneur pour l'intégrer dans SMSForward.
[^] # Re: Merci
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche Sortie de R.A.S. v0.5, alias RandoAmisSecours. Évalué à 6.
Sans rigoler ça pourrait être une option activée uniquement si l'utilisateur le souhaite.
Je pensait permettre aussi d'uploader régulièrement la position GPS depuis le téléphone vers l'application. La trace serait alors visible pour les amis de la personne si et seulement si celle-ci est en retard (et qu'elle a activé la fonction dans l'application Android).
Je pensais aussi supprimer automatiquement les données GPS dés que la personne indique être rentrée.
[^] # Re: HTTPS
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche Sortie de R.A.S. v0.5, alias RandoAmisSecours. Évalué à 2.
Merci pour le liens. Je vais voir ce que je peux faire sachant que j'ai choisie la liste de cipher assurant une bonne compatibilité avec les navigateurs et OS existants. Je peux faire mieux en supportant moins de navigateurs.
Tu as aussi raison pour le HSTS : je vais le rajouter.
[^] # Re: Merci
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche Sortie de R.A.S. v0.5, alias RandoAmisSecours. Évalué à 7.
L'instance qui tourne sur randoamissecours.org est faites pour être utilisée directement par les personnes intéressées.
Le site est hébergé sur un serveur chez OVH qui tourne sans problème notable depuis quelques années. J'ai donc plutôt confiance dans la fiabilité de ce serveur.
Si tu souhaite installer R.A.S. sur ton serveur c'est assez facile si tu as déjà configurer Apache pour servir du python.
Je suis bien d'accord avec toi. Je serai d'ailleurs le premier utilisateur de cette fonctionnalité. N'étant malheureusement pas très fort en développement d'applications Android, je n'ai pas encore trouvé le temps de développer cette fonctionnalité. Si quelqu'un sait faire je suis preneur !
[^] # Re: Plan de vol
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche Sortie de R.A.S. v0.4, alias RandoAmisSecours. Évalué à 1.
Si tu sais où trouver cette info je suis preneur !